DockerHubでAutomated Buildsを使った時にDocker Tagがうまく設定できない
OpenSSLでファイルの暗号化/復号化をしたくてAlpineベースのDockerイメージを作成しました。
ググったら同じようなものがあったのですが、OpenSSLのバージョンやCA証明書が古かったりで使いにくかったので作成しました。
どのバージョンのOpenSSLが入っているか・または指定できるようにtagをつけて管理したいと思い、Automated Buildsでtagをpushした時に自動でつけられるようにしたかったのですが、ちょっとハマったのでメモ。
何をしたか
デフォルトでmasterブランチを対象に latest とtagを振ってくれるRULESがあるのですが、今回はtag名にしたかったので不要と思い削除しました。
その上でGitのtagを見てそれをDocker Tagになるように設定したのですが、 Docker Tag の部分がうまく指定できなくなりました。具体的には、何を入力しても latest になります。
設定できそうに見えるのですが、保存すると Docker Tag が latest に置きかわります。
latest tagを振るRULESが最低1つは必須なんだと思い、はじめにあったRULESを追加してもダメでした。
どうやら 一番上が優先される ようで、削除して latest が一番上に来るようにRULESを指定することで思ったように指定できるようになりました。
思えば latest のtagが振られていないものってないなと思い、それから逸脱するような指定はできないようになっているんだなと納得しました。
まとめ
- RULESは上にあるものが優先される
- latest tagの指定は必要
- 一度tagをつけてAutomated Buildsに成功した後は
latesttagの指定を削除しても設定できるようになりました。一定の環境下でないと起きないのかもしれません。
- 一度tagをつけてAutomated Buildsに成功した後は
参考
2018年を振り返って
すでに2019年が10%以上過ぎてますが、2018年の振り返りをまとめてなかったのでまとめておきます。
はじめに目標としてたことに対して振り返ります。
目標としてたこと
- 自炊の回数を増やす
- 12月から自炊を再開しました。相変わらずパスタ一辺倒です。振り返ってみると、引っ越ししてから2年以上自炊をしてませんでした。すごい。
- 体を鍛える
- 結局何もしなかったです。しかし続きがあります。
- Android以外のこともする
- iOSアプリを作り始めたのはいいですがモチベーションと進捗の折り合いがつかず、結局頓挫しました。しかしそのときにReactorKitというFluxベースのフレームワークを使い、Fluxの世界に興味をもつことが出来ました。
- Google Assistant周りの何かをする
- Nature Remoとiftttの既成品の連携だけで、特に開発はしなかったです。
- Fitbit ionicのWatchFace作る
- 正しくはClockFaceなのですが、こちらは作ることが出来ました。追い込まれるとやっぱりやらざるを得なくなります。
結果だけ見ると着手は半分以上できてるという結果にはなりますが、個人的にはそんなにやったった感は感じてないです。むしろ出来てないなという感じです。新規アプリ開発も公開までしたものはありませんでした。
やったこと
インサイダー・ゲームの拡張を作ろうとした
インサイダー・ゲームというボードゲームがあるのですが、出現するワードがカードに書かれている限りなので、そのワードを拡張して楽しめるようにできるアプリを作ろうとしました。
- ワードの分類
- ワードの保存
- ワードを追加する機能
- 分類したワードを表示する機能
とかが必要になるので、始めにワードの分類をしようと思い、ベクトル化をするところまでやってモチベーションの灯が消えてしまいました。
DockerHubにもあげてあるので動かしてみることは出来ます。
技術書典に参加した
技術書典5に出店側として参加しました。そのときにClockFaceの作成と同人誌作成をしました。
詳細は別記事にまとめてあります。
ClockWaceを作った
技術書典で本を出すにあたり、作ってみました。当初はApple Watchという名前を入れていたのですが、ストアでレビューで落とされてしましました。一粒で二度美味しい体験ができました。
競争相手があんまりいないからか、ユーザから問い合わせがちらほらくるので、2019年はガチなやつを一つ作りたいなと思ってます。
jib触った
前述のベクトル化するコードのdocker化や、会社でのツールなどに活用しました。
Kotlin/Nativeちょっと触った
AlfredのWorkflowに使いました。多分やってる人はまだ他にいないです。
趣味とかその他
ボドゲにハマった
ハマりました。どれくらいかと言うと、自分でも買うしゲムマにも行くしボドゲを作るワークショップにも参加するくらいです。
2018年にこれだけ買いました。
- ごきぶりポーカー
- トロイカ
- ドミニオン
- ドミニオン(海辺)
- ナショナルエコノミー
- ワンナイトマンション
- パンデミック
- チケット・トゥ・ライド(ドイツ)
- ザ・マインド
- Tokyo Highway
- リキュール・ザ・ゲーム
- CESSPOOL：REMASTERED
ちなみに今年もすでに買い始めてます。
コーヒーにハマった
家で豆を挽いて飲むようになりました。スタバみたいなカフェミストを家でも飲みたいと思い、クリーマーを購入しました。
あとはマキネッタを買って、より濃いコーヒーでカフェミストを作ったりしてます。夏には水出しアイスコーヒーも作りました。
ハンドドリップ用に計りを買いましたが、安定したドリップにも貢献してくれるしそれ以外にも便利なので計りは一家に一台おすすめです。
2019年
すでにいくつか始めていることがあります。
ジム通い始めた
周りにやるって言っちゃったので勢いで始めました。今の所苦なく続いてます。会社帰りに通えるのは自分の中でマストだなと思いました。形から入るので、アンダーアーマーのコンプレッションウェアも購入してます。
競プロ始めた
基礎が弱いのはわかっていたので、学ぼうと思い始めました、筋トレと同じく、目が出たと思うタイミングが来るのかもしれません。
目標
OKRの本を読んで、会社としても導入しています。個人の目標も時期を区切って、OKRという形でやってみようかなと思ってます(すでに1ヶ月経ってるけど)。
Node.jsを使ったアプリケーションのサンプル集にlernaを使うと便利だった
先日参加した技術書典でFitbitのClock Faceの作り方に関する本を出しました。サンプルコードを添えたのですが、そこで使ったlernaが今回のようなケースと相性が良いと感じたので紹介します。
今回のケース
1つのリポジトリに複数のNode.jsのアプリケーションを配置しました。そしてそれらは同じ devDependencies を持っています。
複数のアプリケーションが存在していて
.
├── LICENSE
├── README.md
└── packages
├── package1
│ └── package.json
├── package2
│ └── package.json
├── package3
│ └── package.json
└── package4
└── package.json
それぞれのpackage.jsonに次のような記述がある
{ "name": "package1", ... "devDependencies": { "@hoge": "1.0.0", "@fuga": "~1.0.0", "@piyo": "^1.0.0" }, ... }
問題と思っていたこと
このようなサンプル集のリポジトリで各サンプルを動かしたい場合は、クローンしてきたあとにそれぞれのpackageのなかで npm install を実行する必要があります。
単純に数が増えてくると手間だというのと、同じ依存関係を持つ .node_module/ が各package配下に重複してできてしまい、ディスク容量を圧迫してしまいます。
簡単にサンプルを実行可能な状態にして、重複する依存関係はよしなに参照するとかしてほしい。
lerna
lernaはmonorepo管理用のツールです。npmに公開するところまでサポートしてます。
今回はlernaの機能の一部を使って問題を解決します。
使い方
新規の場合
$ lerna init
で必要なものを作成できます。
. ├── lerna.json ├── package.json └── packages
packages の中に各プロジェクトを配置します。
モジュールの追加
モジュールのインストールは各package直下だけではなく、プロジェクトルートで lerna を使って行えます。
$ lerna add ${モジュール名} --dev
これで packages 配下のすべての package.json に ${モジュール名} が追加されます。各package直下で npm install ${モジュール名} --save-dev したことと大体同じになります。
cloneしてきてから初期化
プロジェクトルートで次のように実行すればすべてのpackageを初期化できます。
$ lerna bootstrap
重複をまとめる
まず既存の node_modules/ を削除します。cloneしてきた直後だと不要です。
$ lerna clean
先程のbootstrapにオプションを付けて実行します。
$ lerna bootstrap --hoist
--hoist オプションをつけることで、package共通で使うモジュールは プロジェクトルートの node_modules/ にインストールされます。各package配下では、 共通利用しているモジュールのみ node_modules/.bin/ にシンボリックリンクが生成され て利用可能になります。
プロジェクトルートの node_modules/ は lerna clean では消去できないので注意してください。
今回のサンプルコードだと --hoist オプションを使うことでディスク容量を半分以下に抑えられました。モジュールの種類や依存状況にもよりますが、 同じようなものを共通して利用するサンプル集のような場合だと、サンプル数が多ければ多いほど効果が出てきます。
- hoistなし
$ du -sch * 4.0K LICENSE 4.0K README.md 4.0K lerna.json 4.0K package.json 518M packages 518M total
- hoistあり
$ du -sch * 4.0K LICENSE 4.0K README.md 4.0K lerna.json 152M node_modules 316K package-lock.json 4.0K package.json 99M packages 252M total
--hoist オプションを使うとファイル容量を節約できますが、前述の通りpackageから見たら通常 インストールされているモジュールの位置が異なるので lerna で管理可能なもの以外で パスを参照している場合注意が必要です。
まとめ
lerna はmonorepoの管理だけでなく、次の場合にも便利です。
- Node.jsのサンプル集を扱うとき
- サンプルの一括セットアップをしたいとき
- ディスク容量の節約がしたいとき
- まとめた場合共通モジュールの参照先が変わるので注意
参考
lerna/lerna: A tool for managing JavaScript projects with multiple packages. / GitHub
