docker に push する先を typo してたまま CI 回しててしばらくずっと間違ったところに push してました。
oneapi が正しかったのに openapi ってなってました。
ここで今までビルドしたイメージを openapi から oneapi の方に移したいなと思ったのですが、これをやる場合 openapi から pull して oneapi に push するだけではあるのですが、すべてのタグでやるのはめんどくさかったのでスクリプトにしました。
./docker-cp-repo.sh srzzumix/openapi-cxx srzzumix/oneapi-cxx
のように使います。
jq 使うと repository のタグ一覧が簡単に取れるので便利です。
今回は以上。では。
https://hub.docker.com/repository/docker/srzzumix/iwyu/general
表題どおりです。
今まで自分が使うようにイメージを置いといただけでしたが、各 clang バージョン x Ubuntu バージョン x Multi Arch(amd64/arm64) でビルドしておいておきました。
Include What You Use は C/C++ の include の最適化をしてくれるツールです。
過去に記事を書いてますのでそのへんを参考にしてください。
「ブログズミ: [C++] Include-What-You-Use で依存関係を確認する」
ビルドは GitHub Actions で行っています。
https://github.com/srz-zumix/docker-iwyu
今後は複数 arch 対応の需要が上がっていく気がしてるので今回から対応してみました。
複数 arch 対応の image をローカルでビルドする場合は、レジストリに push しながらなら OK らしく（ようは実行環境の arch しかローカルビルドできないって感じかな？）勉強になりました。
今まではビルドしたあとにタグつけて push してたのですが、これだと実行環境の arch しか push できなかったため、一度ビルドしたイメージからバージョン情報とかを取り出し、タグを生成してから再度 docker/build-push-action を実行してます。
これらのイメージは定期的にビルドするものでもないので手動トリガーでビルドするようになってます。
一部の組み合わせではビルド失敗したり、clang のインストールできなくて image のビルドに失敗してます。
需要があればちゃんと見てみますので、もしあれば issue に書いてください。
以上。
DockerHub の料金改訂により Automated Build が無料プランでは使えなくなりました。
Changes to Docker Hub Autobuilds - Docker Blog
DockerHub に image push するのに一番楽で良かったのですが、しょうがないですね。
今は GitHub Actions があるのでそこから build して push するのが簡単だと思うので、そちらに移行しました。
移行したリポジトリたち
build と push は アクションを使えばとても簡単です。
下記、もしくは上記リポジトリの workflows を参考にしてみてください。
さて、定期的なビルドは GitHub Actions の cron トリガーを使えばすぐに対応できます。
また hook の post_push も必要な環境変数を与えたうえで run すれば問題ないでしょう。
問題は Webhook トリガーで、私の場合は PyPI や gems のリリース RSS をトリガーに Webhook を叩いてビルドしていました。
例：「ブログズミ: PyPI のリリースを検知して Dockerhub の image を更新する」
これを GitHub Actions でやる場合は「workflow_dispatch」を使うことになると思います。
actions 側は特に難しいことはなくて、on のところに workflow_dispatch を追加するだけです。
一方 Webhook を送信してた側は dispatch イベントを API で送信することになります。
API ドキュメントは↓
Actions - GitHub Docs
以下は、Integromat で dispatch イベントを送る設定方法です。
repo 権限のついた GitHub の Personal Access Token が必要なので発行しておきましょう。
URL には下記の {} で囲まれた部分を適宜変更して入力します。
/repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches
workflow_id は Action を開いたときの URL でわかるとは思いますが、面倒なのでファイル名指定がおすすめです。（ファイル名には拡張子も含める必要があるので注意してください）
Method は「POST」、
Headers には「Name: Accept, Value: application/vnd.github.v3+json」を追加します。
Body type を「Raw」にし、Content type は「JSON (application/json)」にします。
Request content には「{ "ref": "master" }」（今は main の場合もあるでしょう）を入力します。workflow_dispatch には任意の input パラメータを設定できますが、それらの設定はここにつけ足すことになります。
設定できたらモジュールを右クリックし、「Run this module only」を実行して、トリガーできるか確認しましょう。
Integromat での設定例を紹介しましたが、他の場合でも対応方法は同じような流れになると思います。
今回は以上。では。
これらのつづき
Azure Pipelines の場合は以下を参考に「Project Settings」の「Service connections」を開き、「Docker Registry」を追加すれば OK です。
Registry Type に DockerHub があるので、それを選択して、ID/パスワード（トークン）をセットします。
Service connections in Azure Pipelines - Azure Pipelines | Microsoft Docs
今回は以上。
Linux 版 Unity 使いたいので UnityHub CLI でインストールしようと思ったらめんどくさかったので備忘録。
「Feedback - Headless Mode Isn't Really Headless - Unity Forum」
なにが面倒だったというと、 headless モードが headless モードじゃなくて docker とか VM とかでディスプレイない環境だと起動ができないのです。
こんな感じのエラーで起動できません。
(unityhub-bin:919): Gtk-WARNING **: 08:08:17.580: cannot open display:
で、xvfb で回避できるのですが、すでに回避策を講じた Docker image を同僚に教えてもらいました。このイメージを使ったら Unity のインストールとかの自動化も簡単にできそうです。
https://hub.docker.com/u/unityci
Dockerfile はこれ
https://github.com/game-ci/docker/blob/main/hub/Dockerfile
中身を読むとわかりますが、AppImage をばらして xvfb-run してます。
ちょっと気になるのは、ばらした AppImage が / に展開されることくらいですかねぇ。
Docker なら、まぁいいかもしれませんがどこかのインスタンスに入れるなら嫌だなぁと思ったので、自分なりに書き直してみました。
できあがったイメージと Dockerfile はこちらです。
https://hub.docker.com/r/srzzumix/unityhub
https://github.com/srz-zumix/docker-unityhub
PR のコメントとして残してあります。
以上、回避策など取らずに使えるようになってくれると嬉しいですね。では。
無料になったIntel compilerをCentOS8にインストールしてみる - Qiita
Intel compilerが2021年になってから実質的に無料になってしまったというのを知り、勢いで作ったのが↓のリポジトリ
https://github.com/srz-zumix/docker-icx
（現在は名前変えてます。https://github.com/srz-zumix/docker-oneapi-hpckit）
公式がサポートしてない Ubuntu 16.04 で oneAPI のセットアップをしてます。
（intel-basekit と intel-hpckit。パッケージリストはこちらを参照）
で、いつもどおり DockerHub の Automated Build でビルドしたんですが、「No space left on device」でビルドできませんでした。
デカイからなぁ・・（上が公式、下が自前）
space を増やすのもめんどくさそうなので、別の CI サービスを使おうと考え、GitHub Actions でビルド、DockerHub に push するようにしてみました。
（とりあえず build までで https://github.com/srz-zumix/docker-icx/blob/main/.github/workflows/dockerhub.yml）
「No space left on device」！！
ググると prune しろとか出てきたので試すも変わらず。うーん。
じゃあ、しょうがないし他のサービスにするか。
というわけで次点で CircleCI ！というふうに決めたわけじゃないです。
拙著「あつまれ CI サービス タダではじめる継続的インテグレーション生活」に記載されている各CIサービスの実行環境の空きディスク容量を参考にして小さいサービスを避けて決めました。
というわけで、CircleCI でビルドしました。
目論見通り成功です！
作ったイメージはこちらにあります。
https://hub.docker.com/r/srzzumix/oneapi-hpckit
とはいえ、公式のイメージがあるので特に理由（Ubuntu 16.04 じゃなきゃだめとか）がなければそちらを使うのがいいと思います。（↑のは１レイヤーにまとめすぎて pull が遅い…）
https://hub.docker.com/r/intel/oneapi-hpckit
また intel-oneapi-compiler-dpcpp-cpp-and-cpp-classic パッケージだけをインストールしたイメージも作ったのでこちらに置いてあります。
https://hub.docker.com/r/srzzumix/oneapi-cxx
hpc-kit は結構イメージサイズがデカイので、 C++ Compiler だけ欲しい人がそのパッケージだけインストールしたイメージを作ると良さそうです。
私はこちらを Intel C++ Compiler でのビルド・テストに利用したいと思ってます。
今回は以上。ではでは。
#!/bin/bash
set -eu
if [ "${DOCKER_TAG}" = "latest" ]; then
LIZARD_VERSION=$(docker run --rm ${IMAGE_NAME} --version)
docker tag ${IMAGE_NAME} ${DOCKER_REPO}:${LIZARD_VERSION}
docker push ${DOCKER_REPO}:${LIZARD_VERSION}
fi
ブログズミ: [CodeShip][Drone.io] DockerHub pull rate limit に対応する
こちらに引き続き、Wercker での対応方法をまとめます。
その前に Wercker は Oracle に買収されてから手付かずな状態なのかと思ってましたが、
Slack コミュニティは生きていて今回の対応方法も Slack コミュニティで知りました。
まだ Wercker 使ってる人は入っておくといいと思います。
では本題の対応方法です。
Box に対しては以下のように box 指定で user/pass を設定します。
box:
id: python
username: srzzumix
password: ${WERCKER_DOCKERHUB_PASSWORD}
ステップ内で docker 使う場合は普通にログインすれば OK です。
- script:
name: Login DockerHub
code: |
echo ${WERCKER_DOCKERHUB_PASSWORD} | docker login -u srzzumix --password-stdin
今回は以上です。
では。
DockerHub の pull rate limit への対応方法メモです。
基本的には DockerHub にログインした状態で pull することになると思います。
ログイン情報のパスワードには DockerHub の設定から API トークンを発行しそれを設定します。
ただ、このユーザー/パスワードを各 CI サービスに適用する方法はサービスによって違います。今回は CodeShip と Drone.io の設定を紹介したいと思います。
CodeShip Pro の場合です。 Basic の場合はコマンドの中で docker login コマンドを実行する方法になると思います。
Using Docker Image Registries | CloudBees Docs
上記リンク先のドキュメントに設定方法が記載されています。
手順としては大きく分けて２つで、Dockerconfig.json の用意とリポジトリ/ YAML の設定になります。
まず DockerHub にログインするための config.json を生成します。
{
"auths": {
"https://index.docker.io/v1/": {
"auth": "your_auth_string",
"email": "your_email"
}
}
}
json ファイルの中身は上記のようなものになります。
この json ファイルは docker login したら $HOME/.docker/config.json に保存されるものを使えばよいのですが、macOS の場合保存場所が keychain になっているため、下記方法で取得します。公式ドキュメントでは「Docker Credentials On Mac OSX」のあたりです。
まずは以下のような credentials.evn ファイルを作成します。
USERNAME/PASSWORD は適宜埋めてください（PASSWORD には API TOKEN）
DOCKER_USERNAME=... DOCKER_PASSWORD=... DOCKER_REGISTRY=https://index.docker.io/v1/
続いて、以下のコマンドを実行します。
mkdir ./dockercfg
docker run -it --rm \
--env-file=credentials.env \
-v "$(pwd):/opt/data/" \
-v "/var/run/docker.sock:/var/run/docker.sock" \
codeship/dockercfg-generator /opt/data/dockercfg
すると、カレントディレクトリ/dockercfg/ に config.json が出来上がります。
config.json が出来上がったらそれをシークレットファイルにして、CI 環境が読み込むように YAML に設定をします。
シークレットファイルの作成のためにプロジェクトの設定ページから codeship.aes をダウンロードしてください。リポジトリのルートに配置したら不用意に commit してしまわないように .gitignore に追加しておきましょう。
aes を配置したら以下のコマンドを実行します。パスは適宜変更してください。
jet encrypt dockercfg/config.json dockercfg.encrypted
出来上がった .encrypted ファイルは git add/commit します。
続いて YAML の設定をします。
追記するのは codeship-steps.yml ファイルの方です。
以下のように encrypted_dockercfg_path を追加してください。
- name: spec service: gcc command: /work/build.sh encrypted_dockercfg_path: ./dockercfg.encrypted
これで設定は以上です。変更を commit/push して動作確認してみましょう。
うまく設定できていれば DockerHub の Token 一覧画面で最終アクセス日時が更新されるはずです。
Images | Drone
Drone の公式ドキュメントはこちらです。
CodeShip と同じように Dockerconfig.json ファイルを作成し、それを drone のシークレットファイルとして CLI から登録します。
iutest で生成用に用意した Makefile があるので参考にしてください。
https://github.com/srz-zumix/iutest/tree/master/.ci/drone
json ファイルを作成したら以下のコマンドで登録できます。
drone secret add --repository srz-zumix/iutest \ --name dockerconfig \ --data @dockerconfig.json
シークレットファイルをアップデートする場合は update サブコマンドを使います。
drone secret update --repository srz-zumix/iutest \ --name dockerconfig \ --data @dockerconfig.json
PR でもこのシークレットファイルを利用可能にする場合は --allow-pull-request オプションを追加してください。
シークレットファイルを登録したら以下のように、このファイルを使用するように YAML の設定をします。
kind: pipeline name: test image_pull_secrets: - dockerconfig steps: ...
image_pull_secrets に指定するのは secret add/update したときに指定した --name オプションの名前です。
設定は以上です。
CodeShip と同様にトークンが利用されたかどうかを確認しましょう。
今回対応した CodeShip/Drone どちらも Dockerconfig.json ファイルをシークレットに用意してそれを環境に読ませる方法でした。
最初 Drone の方は
echo -n '<ユーザ名>:<アクセストークン>' | base64
の結果を auth に設定していて、それではうまくいかなくて手こずっていたのですが、CodeShip のやり方を知って助かりました。
（Mac 環境で base64 してるのが原因？）
ともあれ、CodeShip や Drone と同様に Docker の config.json を使った login をする CI サービスではこの方法が使えそうです。
今回は以上です。
#!/bin/bash
# post_build
VERSION=$(docker run --rm ${IMAGE_NAME} --version)
docker tag ${IMAGE_NAME} ${DOCKER_REPO}:${VERSION}
docker push ${DOCKER_REPO}:${VERSION}
特に懸念されていたのは CI サービスでの制限です。
DockerHub にログインしていない場合は IP に対して制限がかかるため、利用者の多いサービスではあっという間に上限越えて、制限がかかってしまうことが予想されました。
これに対し、すでに（期限付きではありますが）制限を受けないようにする交渉が完了しているサービスもあります。
DockerHub による2020/11からのコンテナイメージ Pull 回数制限のCircleCIへの影響 - Build Environment - CircleCI Discuss
ある程度猶予があるかもしれないですが…
何れにせよ、今後 DockerHub からイメージを pull して CI を回す場合は、事前に DockerHub へのログインをするようにパイプラインを更新しておくのが良さそうです。
それらへの対応方法についても、記事冒頭のドキュメントからリンクが貼られていたり、各 CI サービスから案内が出ていると思います。
筆者が開発している C++ テスティングフレームワークの iutest はめちゃくちゃたくさん CI サービスを使っているので（Docker 関係ないものもあるので全部ではないが）絶賛対応中です。
対応方法はログインするだけなんですが、各サービスやり方が異なるのでここでは対応方法は省略します。
一応、状況はこちらの issue で確認できます。
https://github.com/srz-zumix/iutest/issues/519
https://t.co/E8DUTOMi4M
— ずみっくす@あつまれCIサービス (@srz_zumix) October 23, 2020
DockerHub の pull 制限回避のためのログイン対応中。
CI サービス多用してるので大変（docker 使ってないものも多いけど）
CircleCI みたいに延命されると嬉しいなぁ・・ pic.twitter.com/UnQaIeY9ih
で、ようやく本題。
このログイン対応をしていて思ったのは、「設定したけど本当にログインした状態で pull できているのかをどう確認したらわからなくて不安」でした。
docker login してるかどうか確認するコマンドってない？
— ずみっくす@あつまれCIサービス (@srz_zumix) October 29, 2020
docker のコマンドに「それ」を確認するものがあればよかったのですが、なさそうだったので以下の方法で確認しました。
「echo a | docker login」
ログイン済みなら以下のように成功となります。
$ echo a | docker login Authenticating with existing credentials... Login Succeeded $ echo $? 0
$ echo a | docker login Error: Cannot perform an interactive login from a non TTY device $ echo $? 1
