ぬうぱんの備忘録

技術系のメモとかいろいろ

作った曲一覧はこちら

bazel 上で圧縮ファイルをダウンロードして pkg_tar rule に組み込みたい

やりたいこと

  • 任意の圧縮ファイルを任意のサーバーから落とす
  • そのファイルの中身をまるごと pkg_tar rule の srcs として取り入れたい

なんで pkg_tar に取り込みたい?

  • container_image rule の tars にそのまま突っ込める
  • コレができると bazel 上での docker image ビルドがとっても楽

やりかた

WORKSPACE ファイルでファイルダウンロードを記述

http_archive(
    name = "my_archive",
    urls = ["<insert your URL>"],
    sha256 = "<insert your hash>",
    type = "<.zip, .tar.gz, .tar.xz, ...>",
    build_file_content = """
filegroup(
    name = "srcs",
    srcs = glob(["**"]),
    visibility = ["//visibility:public"]
)
"""
)

BUILD ファイルで pkg_tar を記述

load("@bazel_tools//tools/build_defs/pkg:pkg.bzl", "pkg_tar")

pkg_tar(
    name = "my_package",
    package_dir = "/opt/local",
    srcs = [
        "@my_archive//:srcs",
    ],
    strip_prefix=".",
    mode = "0755",
    visibility = ["//visibility:public"],
)

filegroupsrcs = glob(["**"])

  • * だとダメで ** が正解
  • * だと最上位階層だけ列挙される

pkg_tarstrip_prefix="."

  • これを書いておかないと圧縮ファイルの中身が平ら(flatten)に展開されてしまう
  • . を指定すればディレクトリ構造がそのまま維持される
  • 公式のドキュメントに思いっきり書いてあった docs.bazel.build

参考

Web API から factorio の headless server をダウンロードする

やること

  • curl で要求するだけで OK
  • linux headless については認証なしでダウンロード出来る模様
curl --location --output /path/to/output/file https://www.factorio.com/get-download/latest/headless/linux64

認証が必要な場合

アクセストークンを取得

username=<username>
password=<password>

access_token=`curl -s -f --data "username=$username?password=$password" https://auth.factorio.com/api-login |  jq -r '.[]'`

パッケージを取得

out_file_path=/path/to/output/file

curl \
    -s \
    -f \
    --location \
    -G \
    --data-urlencode "username=$username" \
    --data-urlencode "token=$access_token" \
    --output $out_file_path \
    https://www.factorio.com/get-download/latest/headless/linux64

利用可能なバージョン番号を取得したい場合

  • https://factorio.com/api/latest-releases を GET することで json 形式で返ってくる
  • experimental と stable の2種類返ってくる

感想

  • official wiki だとなんかごちゃごちゃ書いてるけど headless については全部不要な手順だった wiki.factorio.com
  • これのせいで認証が必須だと思いこんですごい遠回りするハメになった

参考

CGP(GCE)でコンテナを実行する

TL;DR

  • Google Compute Engine で上で任意・単一の docker コンテナを実行して ssh ログインしたい
  • 何でもいいからとりあえずクラウド上でコンテナ動かしてみたいな程度のモチベ
  • ちょっと設定書くだけで済むからめっちゃ楽ちんだよ

1次情報

こちら --> https://cloud.google.com/compute/docs/containers/deploying-containers?hl=ja 要約すると

  • Compute Engine へ docker コンテナをデプロイすることが可能
  • 「デプロイする」が何のことを指すのかは明記されてない
  • インスタンス1コンテナしか想定してないよ

試しに

python コンテナデプロイ付きのインスタンスを作成する

  • Google Cloud Platform にログイン
  • ホーム左枠の「コンピューティング --> Compute Engine --> VM インスタンス」から「インスタンスの作成」を選択
  • 「名前」は適当に埋める
  • 「マシンタイプ」は「f1-micro」に変更
    • こうすると Always Free 枠に収まる
    • テスト目的なので $300 の無料枠は使いたくない
  • 「この VM インスタンスにコンテナ イメージをデプロイします。」にチェック入れる
  • 「コンテナ イメージ」は「python
    • Docker Hub 公式イメージの場合諸々省略してイメージ名だけでも通る
    • フルネームの場合 registry.hub.docker.com/library/<dockerimagename> って書く
  • 「コンテナの詳細オプション」をクリック
  • 「STDIN のバッファの割り当て」と「疑似 TTY の割り当て」にチェックを入れる
    • python コンテナのエントリーポイントは python コマンドになっている
    • チェックを入れないと、標準入力から EOL が入力されるので python インタプリタが即落ちしてコンテナも即落ちする
    • インスタンス起動後にコンテナがずっと restarting になってる場合はこれが原因
  • 「作成」をクリック

コンテナにログインする(on Web)

  • ホーム左枠の「コンピューティング --> Compute Engine --> VM インスタンス」で作成したインスタンスの一覧が表示されてるはず
  • 目的のインスタンスの行の「接続」列の「SSH」をクリック
  • 暫く待つとターミナルが立ち上がる
  • ログイン直後に「エラー起きてるからログ見ろ(意訳)」みたいなメッセージが出てない事を確認
  • docker pspython イメージのコンテナの「STATUS」が「Up」になっていることを確認
  • docker exec -it <CONTAINER_NAME> bashbash ログインしてみる
    • <CONTAINER_NAME>docker ps で表示されたものを入れれば OK

コンテナにログインする(on gcloud)

ローカル PC に Google Cloud SDK を入れてる場合はローカルの端末からログイン可能。

  • 「Compute Engine」の「VM インスタンス」で作成したインスタンスの一覧が表示されてるはず
  • 目的のインスタンスの行の「接続」列の「SSH」の右の「▼」をクリック
  • 「gcloud コマンドを表示」をクリック
  • 「CLOUD SHELL で実行する」をクリック
  • コマンドが表示されるのでそれをローカル PC のコンソールにコピペして実行

ついでに

  • 末尾に --container <CONTAINER_NAME> を追加することでコンテナに直接ログイン可能らしい
  • でも実際やると何故かエラーで落ちる

注意点

  • インスタンス起動中はずっと料金が発生する
  • 無料枠の場合はその枠を消費する
  • 使い終わったらマメに落とさないと大変な事になる

感想など

  • インスタンス起動と同時に任意のコンテナを立ち上げる方法は分かった
  • コンテナの起動設定はなぜか docker コマンドのオプションとの対応関係をボカしててわかりにくい
  • stdin とか tty の設定しないと永久リブートになるやつでハマった
    • docker の事よく分かってなかったってのはある
    • 多分 web サーバーとかの起動しっぱなし系のイメージだとうまく行っていた
  • コンテナの終了をトリガーにしてインスタンスも落としたいんだけど、それをやりたい場合は自分でいろいろ組まないといけないらしい
  • 次はファイルシステムのマップでもやってみるか

参考

2020年のナウいビルドツール

この記事は

  • Linux 環境で使えるナウいビルドツールをまとめた記事です
  • 比較のためにナウくないのも列挙してます

ビルドツール

GNU make

  • 最もベーシックで人間にも優しい
  • プロジェクト規模がデカくなるととにかく重たい
  • ちょっと変なことをしようと思うととたんにうまくいかなくなって悲しい

ninja

  • make の置き換えと言うポジション
  • 何でもかんでも明示的に書くと言う考え方
  • メタビルドツールから触ることを前提にしていて人間に対する当たりが強い

bazel

  • GNU make の代替というポジション
  • 言語ごとに最適化されたプリセットを選んで必要な項目だけを埋める感じのビルドツール
  • 中で何が起きているかわからないのでトラブった時にしんどい?

メタビルドツール

autotools

  • configure, Makefile を生成するヤツ
  • C/C++ のビルドする時のおまじない ./configure --prefix=/path/to/install/dir, make, make install はコイツが由来
  • 設定ファイルを書くのが超辛いらしい

cmake

  • autotools の代替と言うポジション
  • ぱっと見で理解出来るようなものではない
  • 覚えるのめっちゃ大変そう

Meson

  • cmake の代替というポジション
  • Meson で ninja の設定ファイルを書き出して ninja でビルドする感じ
  • Meson 呼んで build ディレクトリに入って ninja 呼ぶっていう3ステップはちょっとイヤ

java

ant

  • javaGNU make といった趣
  • java のサポートが手厚いがそれ以外の言語に使えないこともないっぽい
  • XML でルールを記述すると言う時点でもう無理

Maven

  • ant の代替
  • ビルドツールっていうかプロジェクト管理ツール
  • やっぱり XML での記述

Gradle

  • Maven の後継
  • OSS のビルド自動化のためのツールらしいがやっぱり java のサポートが手厚い印象
  • 本体 + プラグイン + groovy による記述の3段構え

感想

  • こうして列挙してみると進化の歴史を俯瞰した感じありますね
  • 超絶ナウい GNU make を探してたので bazel がすんごい魅力的に感じる

参考

どうしても anaconda から逃げ出したかった

あらまし

今まで anaconda でパッケージ管理してたけど、トラブルまみれでもう耐えられないので pipenv に乗り換えまーす。

環境

vscode 入れる

インストーラー実行するだけのハズなので省略。

python 入れる

Python Releases for Windows | Python.org から最新の x86-64インストーラーを入手。 ほぼ全てデフォルトの設定で OK だが 'Add Python to environment variables' だけ忘れずにチェックを入れる。

pipenv 入れる

適当な場所で cmd を開いて以下のコマンド

pip install pipenv

pipenv を入れる対象はベース python 環境。なので python インストール後1回だけの実行で OK 。 これ以降は pip を使わずに pipenv で管理する。

vscode 拡張

python 拡張だけ入れておく。

vscode workspace をセットアップ

空のプロジェクトを作成する。

  • vsocde をなんにも開いてない状態にする
    • メニューの File から Close Folder とか Close Workspace とか選ぶ
  • フォルダを開く
    • File --> Open Folder
    • プロジェクトのルートにしたいフォルダを選択
  • workspace として保存
    • File --> Save Workspace
    • プロジェクトルートディレクトリと同じ名前にしておく
    • ファイルの保存先はプロジェクトルートディレクトリ直下で

hoge.code-workspace みたいな名前のファイルがプロジェクトルート直下に作成されているはず。 Visual Studio でいう .sln みたいなもので、この .core-workspace ファイルをダブルクリックすると新しい vscode ウィンドウとともに workspace が開かれる。

以降、この workspace を開いた状態の vscode 上で作業を行う。

ワークスペース設定を書く

作成した .code-workspace ファイルをこんな感じにする。

{
    "folders": [
        {
            "path": "."
        }
    ],
    "settings": {
        "files.eol": "\n",
        "terminal.integrated.env.windows": {
            "PATH": "${workspaceRoot}\\.venv\\Scripts;${env:PATH}",
            "PIPENV_VENV_IN_PROJECT": "true"
        },
        "python.pythonPath": "${workspaceRoot}\\.venv\\Scripts\\python.exe"
    }
}
  • 仮想環境をプロジェクトルート以下に作りたいので PIPENV_VENV_IN_PROJECT を書いている
  • 仮想環境の方の pythonvscode拡張機能から参照してほしいので PATH と python.pythonPath を書いている

作業用のターミナルを開く

  • vscode 組み込みのターミナルを開く
    • Ctrl + Shift + `
    • それか Ctrl + Shift + P --> Terminal: Create New Integrated Terminal
  • 以下の点を確認
    • カレントがプロジェクトルートなっている
    • pip にパスが通っている

以下、このターミナル上で作業する。

仮想環境を作成

以下のコマンド

cd
pipenv --python 3

実行後プロジェクトルート以下に .venv と Pipfile が生成されているはず。

試しになんかパッケージを入れてみる

pipenv install numpy

一旦動作確認

Ctrl + Shift + ` でターミナルを開いた時に .venv/Scripts/activate.bat が実行されていれば OK 。 これ以降、ワークスペース内のターミナル下で pip install すると仮想環境にパッケージがインストールされる。

git 管理設定

  • 管理するべきもの
    • hoge.code-workspace
    • Pipfile
    • Pipfile.lock
  • 管理してはいけないもの

注意点など

  • 環境変数 PATH に
    • PATH に仮想環境上の python へのパスを記述している
    • そのため pipenv shell すると同一のパスが二重に展開されてしまう
    • 問題にならないはずなので気にしない
  • インタプリタを明示指定しない
    • Ctrl + Shift + P --> Python Select Interpreter で指定できる(多分 python 拡張)
    • これを使って明示指定すると .vscode\settings.json環境変数展開後のフルパスが書き込まれる
    • ワークスペース設定よりもフォルダ設定のほうが強いので折角書いた設定が上書きされてしまう
    • やらかさないように注意

参考

conda 環境下で mkl のロードに失敗するときの対処法あれこれ

この記事は

conda 環境下で numpy とかの mkl に依存しているライブラリを使いたいときに遭遇する mkl ロードエラーの解決法やら原因やらのメモです。 conda で python 環境を構築するたびに様々なバリエーションをもってハマるのでいい加減メモりました。

続きを読む