Posts for: #Docker

rocky linux も悪くない

#docker  #linux 

2時に寝て7時に起きた。夜うまく眠れなくて夜更かしした。3月になってしまったか。2月の記憶がほとんどない。

rocky linux をベースイメージとして使う

コンテナを作るときのデフォルトの os は、私の中では alpine だが、依存ライブラリの制約があって、いま作っている docker image は rockylinux をベースイメージに使う。rockylinux を docker pull した感覚は速いのでそんな大きなイメージでもない。minimal だと40数 MiB 程度のサイズ。すでに成果物として rpm パッケージがあり、その rpm が依存解決できないといけないため、rhel ベースの os をベースイメージにしないといけない。rpm パッケージに systemd の起動スクリプトなども入っているのでそのまま使えばいいかとも思ったのだけど普通には systemd は動かない。rockylinux のドキュメントにも systemd はこうやったら動くよと書いてあるものの、実際に起動してみるとエラーになる。細かくは追いかけていないけれど、cgroup v2 で未解決な問題があるらしく、cgroup v2 を使うカーネルでは systemd が動かないらしい。

コンテナを動かすプラットフォームがハイパーバイザーも兼ねるので systemd を動かす必要性はないけれど、サードパーティの起動スクリプトを自分たちで保守するのも嫌だなという印象はあるのでもしかしたら悩ましい問題なのかもしれない。

思い立ったらドキュメントを公開

#document  #ci/cd  #docker 

23時に寝て2時頃に少し吐いて起きた。夜遅めに日本酒飲んでいい気分で寝たものの、もう夜に食べたらダメな体になりつつある。4時ぐらいまで起きててそれから寝て7時に起きた。

echo の静的ファイルの扱い

web api のドキュメントは openapi スキーマを使って生成 している。本当はこのドキュメントを gitlab pages で公開させたいのだけど、まだそのインフラ構築ができていなくて先送りになっている。いつもローカルで gitlab ci/cd がビルドしたドキュメントをみていたのだけど、ある機能開発をするときにローカルで web api ドキュメントみるの飽きたなと思って、web api サーバーに同梱してしまえと思い立った。テスト環境の web api サーバーは常に動いているのだから、そこに web api のドキュメントが同梱されていて、なんの不都合があろうか？ (いや、なにもない) 。

次のドキュメントに echo で静的ファイルを扱う方法が書いてある。

ミドルウェアで実装されているようで簡単に静的ファイルを返せる。指定したパスのディレクトリ配下を扱えるのが Static で、指定したパスのファイルを扱うのが File になる。web api ドキュメントのようなものならキャッシュしてもいいなとは思ったものの、次の issue によると v4 ではミドルウェアで自前実装しないといけないらしい。v5 ではその仕組みが echo の機能として入るかもしれない。

その後、gitlab ci/cd で web api サーバーのビルド後、openapi.yml からドキュメント生成をして、任意の static ディレクトリに配置するように設定した。docker のマルチステージビルドを使うと簡単にできる。バックエンドやっていて、サーバーとインフラの両方に手を入れて機能を作っていくときの、うまくできると利便性と達成感の両方を得られるのが楽しい。web api サーバーがドキュメントを提供することは、要件に含まれるわけでも、誰かに指示されたわけでもない。私が勝手にローカルでドキュメントみるの飽きたと思って、勝手に作って、勝手に動くようにしただけ。こういう開発の遊びのゆとりや権限をチームのメンバーにも与えられるようにしていきたい。開発が楽しくて悪いことはなにもないと思うんよね。

dind をやってみた

#gitlab  #ci/cd  #docker  #testing 

3時に寝て7時半に起きた。最後なのでワールドカップの決勝戦をみてた。接戦で試合もおもしろかったしよかったと思う。

gitlab ci/cd で docker in docker

ミドルウェアを伴う結合テストは dockertest というツールを使って docker でミドルウェアを起動して実行している。デフォルトで作成した gitlab runner で docker を使おうとすると失敗する。これは gitlab runner が ci/cd ジョブを docker で動かすため docker in docker (これを dind と呼ぶらしい) のための設定が必要になる。大雑把に言えば gitlab runner にそのための権限を設定する必要がある。gitlab の次のドキュメントに詳細が書いてある。

gitlab runner に権限を設定したら次のような job が動けば docker in docker は成功と言える。

hello-dind:
  stage: test
  image: docker:20.10.21
  variables:
    DOCKER_HOST: tcp://docker:2375
    DOCKER_TLS_CERTDIR: ""
  services:
    - docker:20.10.21-dind
  allow_failure: true
  before_script:
    - docker info
  script:
    - docker run hello-world

あとになって気付いたことだけど、dockertest の README にも Running dockertest in Gitlab CI としていくつか tips が紹介されている。dockertest で作成したリソースからホスト名とポート番号を取得するには次のようなユーティリティを使う必要がある。

func getHostPort(resource *dockertest.Resource, id string) string {
	dockerURL := os.Getenv("DOCKER_HOST")
	if dockerURL == "" {
		return resource.GetHostPort(id)
	}
	u, err := url.Parse(dockerURL)
	if err != nil {
		panic(err)
	}
	return u.Hostname() + ":" + resource.GetPort(id)
}

openapi 勉強会

#docker  #nginx  #tls  #openapi 

1時に寝て7時に起きた。昨日はたまたま遅くなって0時頃に帰ってきたが、最近は22時前後に帰ってくることが多い。疲労困憊。

nginx でつくるリバースプロキシ

ちょっとググってみつかる記事を参考にして設定したらすぐにできた。私は tls 周りの設定に詳しくないのでこういうまとめ記事はとても助かる。インターネットって便利。

openapi 勉強会

昨日の続き。openapi についてチーム勉強会を開催した。wiki に次の目次で説明を書いてその内容を勉強会で話した。ちょうど1時間におさまって内容もわかりやすいものができたのではないかと自画自賛。毎週のチーム勉強会のネタとしてちょうどよい粒度だった。

  • code generator が fork した背景
  • スキーマ駆動開発
    • メリット
    • デメリット
  • OpenAPI スキーマからドキュメント生成
  • OpenAPI スキーマからコード生成
  • リファレンス

余談だけど、過去に働いていた会社の発表資料が slideshare から docswell というサービスに移管されてた。slideshare は広告が鬱陶しいサービスになってしまってひどいユーザー体験だからこれは適切な判断だと思う。

docker compose に期待しない

#gitlab  #docker  #infrastructure  #founding 

0時に寝て5時に起きて7時に起きた。起きたら冷やしたのかお腹痛かったが、まぁまぁ眠れたと思う。

テスト環境の構築

GitLab CI/CD にだいぶ慣れてきてジョブを追加したり改善したりしながらようやくアプリケーションの docker image もコンテナレジストリに push されるようになった。それを pull してきて、テスト環境を docker compose で構築する。Use Compose in production とドキュメントでは威勢がよいが、これが全然イケてない。複数の compose.yml で項目によっては変更したいところを置き換えるといった振る舞いになっていない。例えば、ポート番号などを dev と prod で置き換えたいといった運用の要件を考える。

  • dev.yml
services:
  myapp:
    ports:
      - 18080:8080
  • prod.yml
services:
  myapp:
    ports:
      - 8080:8080

これを次のように指定すると、

$ docker compose -f dev.yml -f prod.yml up -d

実際のサービスは次のように振る舞う。全然あかん。

services:
  myapp:
    ports:
      - 18080:8080
      - 8080:8080

他にもそれぞれの yml ファイルで読み込む environment file のマージなどもよくわからない振る舞いをしていて複数の compose.yml で制御するのは断念した。dry の原則に反して設定は重複するけど、それぞれの環境を個別に compose.yml として管理した方が保守コストは小さくなると私は判断した。複数の compose.yml の使い分けのデバッグを1-2日やった後に諦めてテスト環境の構築は完了した。

年金事務所の住所変更手続き

先週 法務局で法人登記の変更申請 をしていて、そのときに問題がなければ今日から登記事項証明書を取得できると案内をもらっていた。決定書が漏れていて再提出というトラブルはあったものの、最小限の損失で留めたせいか、問題なく登記事項証明書を発行できた。住所の変更だけわかればよいので履歴事項証明書ではなく現在事項証明書を発行してみた。この書類もおもしろくて1つ前の住所といまの住所の2つを確認できる。法務局へ行った帰りに年金事務所へ立ち寄って社会保険の住所変更の手続きを行った。次の3つの書類をもって窓口へ。

  • 登記事項証明書: 番地まで記載されている
  • オフィスの一時使用契約書: ビル名はあるがこのビル名は来月に改名
  • ビル名変更の証明書類: ビル名の変更のみが記載されている

この3つの書類で完全に指定された住所 (Fully Qualified Address: 造語) を丁寧に説明したところ担当者に納得してもらえて事なきを得た。

軽量のコンテナオーケストレーションツールは存在しない

#docker  #kubernetes  #event 

0時に寝て6時に起きた。冷蔵庫に飲みものなくて不安。

docker の swarm mode

昨日から docker の swarm mode について調べていた。

オンプレにコンテナのアプリケーションをデプロイするにあたり、軽量のコンテナオーケストレーションツールはないかと調べ始めた。Kubernetes vs Docker Swarm vs Nomad - the orchestrator wars continue? を記事を読むと、軽量のオーケストレーションツールと言えるのは swarm mode か Nomad ぐらいしかない。docker に付属しているならまずはそれを調べるべきだろうと調査した。そして swarm mode の採用は見送った。現時点でこの機能が廃止されるというアナウンスはないが、あまり保守されておらず、docker 社も積極的に推進していない。近い将来、機能が廃止される可能性が高いと私は判断した。

docker のドキュメントをみながら3台の ec2 インスタンスでクラスターを構築してみて簡単であることは間違いない。コマンド2つで swarm クラスターを構築できる。一通り触ってみて数台のマシンを管理する軽量のコンテナオーケストレーションツールとしては十分だと私は思うけれど、残念ながらこのツールが求められる業務やビジネスは少ないのだろうと思う。みんな k8s に持ってかれたという感じかな。調べていて読んだ記事など。

hannali dao 雑談

Hannali DAO #02 に参加した。

最初は dao とは何かをみんなで雑談してた。私はお仕事しながら軽く聞いているつもりだったのが、議論に口出しして熱中してた。技術的に私が理解できないことが出てくると、私の認識が誤っていたり新しい気付きがあったりする可能性があるので、ついつい詳細を聞いてみたくなる。hannali dao でトークンをばら撒く戦略をみんなで考えていて dao の宣伝をしたら貢献の1つとみなしてトークンをもらえる。私は twitter でいくつか hannali dao のツィートをしていて、1ツィートが 300 PROG とかで、合計で 1250 PROG のトークンをもらった。PROG というのは hannali dao でのみ使えるトークンね。

その後、ウォレットに名前を付けられる ENS (Ethereum Name Service) というサービスがあるのを教えてもらった。ちょうどいくらか ethereum をもってたので metamask に送金して、metamask で ens の登録 (購入) をやってみた。初めて ethereum を使ってサービスの支払いをやってみた。これで私も web3 を完全に理解したよ。ens で名前を登録 (購入) するのに $22.58 、ドメイン名みたいなものでサブドメインも登録できる。サブドメインを付けるのに $2.96 かかり、その ens を metamask に紐付けるのに $7.49 がかかった。metamask に紐付けると https://etherscan.io/ などで検索したときにウォレットのアドレスではなく、ens で購入した名前が表示されるようになる。トランザクションの履歴に名前が付いてそれが誰なのかが他人にもわかってしまうことがどういった影響を及ぼすのか、プライバシー云々の他に私はまだわかっていない。web3 なので購入した名前は一般公開されているものだけど、その名前は知り合いにしかまだ教えていない。暗号資産のウォレットに名前を付けることの意味や体験などをこれから経験してみる。

2021年度の確定申告

#tax  #docker  #jib 

0時に寝て6時に起きた。

確定申告

本当は9時から受け付けなんだけど、昨年早めに行ったら受け付けしてくれたので今年も8時半ぐらいから出掛けていった。家から徒歩5分のところに特設の申告会場があって、行ったらすでに100人ぐらいは並んでいた。整理券を配るために行列を誘導している係員に「書類は作成済みで提出だけです」と伝えると「どうぞ、こちらへ」と行列をショートカットして、書類の作成会場の横にある提出会場へ案内される。朝一なので誰も提出してなくてすぐに応対してくれた。書類チェックして提出完了。会場についてから提出するまでに5分。あわせて10分もあれば確定申告できる。電子申告してもよいのだけど、寄付金の領収書の電子化が面倒なのでまだ紙で申告している。寄付金の領収書が電子化されて添付できるような手軽さになったら電子申告してもよいかもしれない。

github container action の検証

jib という java アプリケーション向けの docker イメージをビルドするためのツールがある。お仕事で使い始めたので雰囲気を理解するために私もサンプルアプリケーションを jib-sample として作ってみた。簡単に設定して java アプリケーションを docker 化できるので感触はよさそう。基本的に java アプリケーションと docker は相性が悪くて、たぶん go で開発するような用途と比較するとサイズがめちゃくちゃでかい。それでも jib を使うと作成された docker イメージのサイズも自分でビルドして作るよりは小さくしてくれる。さすが google という感じ。

この jib-sample の docker イメージを使って github actions のカスタム container action を作ってみたのが gh-actions-container-sample になる。Creating a Docker container action のドキュメントには Dockerfile を使ったサンプルしか紹介されていないけど、docker イメージを直接参照して利用することもできる。

検証作業をしているときに jib-sample リポジトリの github packages が private 設定になっていることに気付かなくて少しはまった。リポジトリの visibility 設定と github packages の visibility 設定は連動していないのでそれぞれで別に管理しないといけない。

また jib で作った docker イメージはデフォルトでは manifest を作ってくれない。

$ docker manifest inspect --verbose ghcr.io/t2y/jib-sample:latest
no such manifest: ghcr.io/t2y/jib-sample:latest

How do I specify a platform in the manifest list (or OCI index) of a base image? のドキュメントによると、manifest に platform 情報を追加するのは incubating feature らしくて、なんか条件付きで設定すれば使えそうにもみえたんだけど、私がやってみた感じだとうまくいかなかった。また必要ならもう一度調べてみる。

docker の勉強

#life  #docker  #github 

0時に寝て6時に起きた。

ストレッチ

ここ1ヶ月ほどお仕事に集中しているのもあるけど、あまりストレッチに意識を割いていない。やるときは集中して注力するのだけど、飽きてくると怠ける性格的なところがある。とはいえ、やめずに続けているといいことがあると経験則からわかっているのでなるべく継続していきたい。今週も特別なことはなにもしていないのだけど、右足の股関節周りに張りがあってあまり調子がよくなかった。今日の開脚幅は開始前163cmで、ストレッチ後167cmで先週よりも数値が悪化している。良くなるときもあれば悪くなるときもある。毎週ストレッチを受けて計測しているとそういう気付きがあること自体、この機会は健康のために役立っているように考えている。

github packages で docker イメージを公開する

docker が流行りだした頃に勤めていた会社の貸与端末が docker 禁止だったので私は docker に乗り遅れて、これまでも誰かが用意してくれたコンテナを使うだけでよかったため、最低限の docker コマンドや docker-compose の使い方しか知らなかった。ちょうどインフラの運用を見直す過程で docker コンテナの作成方法から見直すお仕事ができたのでこの機にいろいろ勉強する。いまどき当たり前なんだろうけど、docker の マルチステージビルド をやってみる。

最初に go のバイナリを選択したのは間違いだったのかもしれない。go のビルド環境を作るベースイメージの選択が難しくて、ビルドはできるけど、作成したバイナリが動かないという状況にはまった。ECSのタスク起動時に「standard_init_linux.go」関連のエラーが出た場合の対処方法 であるように、いろんな不具合がある。ベースイメージの選択やビルドに必要なライブラリがないとそういうエラーになるんだと気付くまでに時間がかかった。

最終的に次のような Dockerfile でマルチステージビルドができた。builder としてのベースイメージの選択によってやり方はいろいろ変わってくるように思える。

FROM golang:alpine as builder
RUN apk add --no-cache git make gcc musl-dev
WORKDIR /work
COPY . .
RUN go mod download
RUN make build

FROM alpine:latest
WORKDIR /
COPY --from=builder /work/bin/sql-executor .
CMD [ "/sql-executor" ]

Dockerfile ができたら Publishing Docker images を読みながら github actions で自動的に docker イメージを github packages に公開する設定をやってみた。リリースを作成したときに docker イメージをビルドして公開する workflow yml を作成した。ほとんどドキュメントのまま。

github actions の実行結果。

github packages 上で公開された docker イメージ。

リリースのタイミングじゃなくてコミットのタイミングでも docker イメージを生成できると思うけど、docker イメージのタグに相当するものをどう付けるかというところは工夫する必要がありそう。

mysql のデータ移行

#life  #docker  #mysql  #event 

23時に寝て2時前に起きて5時に起きて8時に起きた。あんまり眠れなくなってきた。

もくもく会

【三宮.dev】もくもく会 に参加した。もともとオフラインの予定だったけど、オミクロン株の流行でオンラインに変更された。

お仕事である開発環境の構築をしていて docker-compose を使って mysql の環境構築や共有の開発環境にある db2 に接続するために clpplus のインストール方法などを wiki にまとめてた。コンテナにある mysqldump や mysql コマンドを使ってこんな風にデータ移行もできた。

共有の開発環境からデータをエクスポート。

$ docker-compose exec -T mydb mysqldump -h $DB_HOST -C --set-gtid-purged=OFF --skip-triggers $DB > dump.sql

ローカルの mysql にデータをインポート。

$ docker-compose exec -T mydb mysql -h localhost -u root -proot $DB < dump.sql

ストレッチ

いつもは11時からなんやけど、今日は17時40分からだった。カレンダーの予定を変更し忘れてて11時に行って間違えた。今週は2日間ぐらいストレッチしたかな。今日の開脚幅は開始前164cmで、ストレッチ後168cmだった。いつも時間帯が違うので数値も変わる。今日は右太ももの内転筋や内側やらがすごく張ってた。あまり調子はよくない。

docker の勉強

#docker  #founding 

0時に寝て2時過ぎに起きて5時に起きて6時に起きた。珍しく3回ぐらい起きた。

docker のマルチステージビルド

これまで docker を使った開発を主導してこなかったので私はあまり docker についての知識をもっていない。いま k8s クラスターで java アプリケーションの運用をしていて、リリース作業の改善には docker イメージのビルドも改善する必要性が迫られてきた。いくつかプラクティスの記事を読んでいると マルチステージビルドの利用 を推奨している記事が多い。マルチステージビルドをうまく活用することで、docker イメージサイズの削減と日々の ci やビルド時間の短縮の2つを図れるようにみえる。docker の仕組みを学ぶちょうどよい機会なので主導的な立場でこの改善に着手しようと考えている。

オフィス内覧

オフィスの引っ越し調査のために エリンサーブ に行ってきた。駅近でもなく市街でもなくちょっと辺鄙な海外沿いにあるせいか、他のレンタルオフィスと比べて全体的に広さに対する家賃は安く設定されている。案内をしてくれた代表の方が「狭い部屋で働かせたくない」といった想いを話されていたので、意図的に窮屈なスペースにならないように広めに設計されているらしい。

オープンスペースでそれぞれの席が別会社という作りは斬新な考えとも言えるし、お互いの信頼関係で成り立っているとも言える。例えば、パソコンのモニターや資料とか、近くを通ったらみえてしまうわけだし。そういったセキュリティも考慮して、一見さんのドロップインには対応していないという。利用者はお互いに面識のある一定の信頼関係を築ける人たちで構成されているらしい。なにか審査があるのかどうかわからないが、人間関係が苦手な人には向かないスペースにもみえる。私は1日のうちにテレビ会議を何度もやるのでオープンスペースだと顧客の情報を守る義務があるのと、そうじゃなくても周りにも迷惑がかかるので、1日のうちの何度も場所を変えてテレビ会議できる部屋に移動しないといけない。それがボトルネックだなと思えた。個室もいくつかみせてもらって、2人向けの窓のある個室があってよさそうにみえた。そこはテレビ会議しても問題ないとのこと。家賃も予算にあうものだった。

Dタイプ(3F)

  • 月額利用料: 66,000円

Eタイプ(3F)

  • デスクは2つ
  • 月額利用料: 76,000円

いまは他の会社が借りている状態だけど、空きが出たら教えてもらえるようにお願いして帰ってきた。