GItLabのコンテナレジストリからタグのリストを取得する

 Dockerのイメージレジストリにあるイメージのタグをリストで取得したい。Dockerレジストリの公式に以下のAPIがある。
/docs.docker.com/registry/spec/api/#listing-image-tags

 GitLabもこれ踏襲してるだろーと"/v2/***"にアクセスしたら404。調べてみたら別のパスで用意しているらしい。
/gitlab.com/gitlab-org/gitlab-ce/issues/40826

 まず↓の形のパスにアクセスして"id"を控える。
/gitlab.com/$PROJECT_PATH/container_registry.json

 あとはその"id"を↓に入れてアクセス。
/gitlab.com/$PROJECT_PATH/registry/repository/$registry_id/tags?format=json
comment: 0

JavaScriptでバイナリをいじる方法を考える(決定打はない)

 ブラウザでFileAPIが実装され、Node.jsでもファイルのIOができるようになって久しい。JSで書いたライブラリでバイナリを扱っているので、その方法を数年ぶりに考察してみる。

 まずFileAPIで返ってくるDataURI。これはASCIIでバイナリを表示できるようにと考え用意されたもの。JSでの型はstring。
 ブラウザではこの形式で画像を読み込んでくれる。しかしASCII化するためにデータ量が30%以上膨れ上がり、何バイト目のデータはいくつかという値取得などの操作も難しい。バイナリを操作するのに向いていない。

 UInt8Array。まさにバイナリを操作するのに実装された型。メモリ上でのデータの扱いも合理的になっている。1バイトを符号なしのショートの整数として扱える。
 ただいまいち任意の場所のデータ比較がいけてると思えない。Pythonならこう
data[0:2] === b'\xff\xda'



 JSでは…配列同士の比較ではダメかっていうとダメ。↓のはfalse。
data.subarray(0,2) === new UInt8Array([255, 0]);



JSではいちいち切り出して、それを比較しやすいstring型に変更して、という手順をふまなきゃいけない。
String.fromCharCode.apply("", data.subarray(0, 2)) === "\xff\xda"




 それがいやならUInt8Arrayではなくstringを使っておくとか。
data.substring(0, 2) == "\xff\x00"



 ただしstringの弱点は、console.logで表示したときにUnicodeで表示されてしまうこと。そのままではデバッグが困難。
let foo = "\xff\x00";

console.log(foo); / ÿ


 UInt8Arrayの部分比較がもっと楽だったらなー。そういうわけで個人的に決定打はなかった。
comment: 0

Docker,Alpine,Let's Encrypt,NginxでHTTPS化を行うリバースプロキシコンテナ

 Let's Encrypt、Docker、NginXを組み合わせて、自動で証明書更新をしてくれるリバースプロキシコンテナを用意している記事を見つけた。だがhttps-portalっていう、同じことをやるDockerイメージもすでにあったりする。
 https-portalとそのブログ記事のあいだに、ぼくも同様のものを作っている。このブログはそのDockerイメージを使ってHTTPS化して動いている。
 実装は自分に必要な機能に絞った。単一の証明書の取得、自動更新、リバースプロキシ。先に挙げた二つのDockerイメージは複数のサブドメインの証明書を取得できるようにしているが、個人的に必要なかったので証明書は一つにしておいた。今ならワイルドカード証明書取れるようになってるし。

623-755-0929
/hub.docker.com/r/matoba/cdcc/

 ↑がそのソースとDockerイメージのリポジトリ。そもそもhttps-portalを使わなかったのは、そっちのソースを見てRuby入ってるのはなくてもできるだろうから軽量化できるなと思ったり、ちゃんとcertbotでの処理を理解しておきたかったから。
 機能を絞った代わりにちゃんと軽量化は果たしていて、https-portalは90MB超なところをぼくのは30MB未満。またSSLのセキュリティもちゃんと調整してSSLLabsでA+の評価を得られるようにしている。


 Let's Encryptやるコンテナを使うTipsとしては、ディレクトリ”/etc/letsencrypt”に外部ボリュームをマウントしたほうがいい。Dockerコマンドなりcomposeで設定できるから。じゃないと発行済み証明書がどんどん廃棄されていって、すぐに発行回数上限に達してしばらく使えなくなってしまう。
comment: 0

Azure PipelinesでGithubプッシュによる自動ビルドを行うブランチを追加する

 AzureでCI/CDができるAzure Pipelinesが、OSS向けはけっこうよさげなリソースで無料利用可能との発表があったので早速触ってみた。既存のプロジェクトに、紹介ビデオを見ながら導入。
/docs.microsoft.com/ja-jp/azure/devops/pipelines/index?view=vsts

 やってみたのはいいんだけど、master以外のブランチでもGithubへのプッシュによる自動ビルド起動に手間がかかったのでメモ。

 ドキュメントに、「YAMLにtriggerを書かなければすべてのブランチで自動ビルド実行されるよ」と。されんかったぞ。triggerで対象ブランチを書いてもだめ。設定ページで「YAMLの設定をここでオーバーライドする」とあったのでそれを切ってもだめ。結局、設定ページで一つずつ対象ブランチを追加するしかなかった。


 そういうわけで設定ページまでの行き方を残す。とりあえずmasterブランチのビルドパイプラインは、ビデオに従った手順でできているとする。

 ”Edit”を選択


 ”Trigger”を選択し、branchフィルターでビルドを行いたいブランチを追加。
(323) 990-5102

 以上で任意のブランチのGithubへのプッシュで、自動ビルドが走るようになる。
comment: 0

9785095958

 CircleCIでCIをする。Dockerやるならそのアウトプットはコンテナで出てくる。CircleCI 2.0でビルド、テスト、デプロイとステージで環境がわかれてる。どうやってビルドしたコンテナを持ち越せばいいんだと。
 ステージ間でディレクトリを共有する仕組みと、Dockerのほうでイメージを単体ファイル化、およびそのロードをする仕組みを使って、ステージ間でのDockerイメージ持ち越しをやってみた。わりと最小構成になるように書いた。
/circleci.com/gh/hMatoba/PlayCircleCi/46

 
config.yml

version: 2.0
jobs:
build:
docker:
- image: alpine

working_directory: ~/repo

steps:
- run: mkdir -p /tmp/workspace/docker
- run:
name: install docker
command: |
apk update
apk add docker
- checkout

# ↓コンテナの中でコンテナを使えないことを考えると、リモートのDockerを使うのに必須っぽいおまじない
- setup_remote_docker:
docker_layer_caching: true

- run:
name: build
command: |
docker pull alpine
docker save alpine > /tmp/workspace/docker/alpine-image.tar
# ↑Dockerイメージのファイル化
# 持ち越したいファイルをディレクトリごとアップ
- persist_to_workspace:
root: /tmp/workspace
paths:
- ./


deploy:
docker:
- image: alpine

working_directory: ~/repo
steps:
- run:
name: install
command: |
apk update
apk add docker
apk add ca-certificates # ↓でのattachに必要
- run: mkdir -p /tmp/workspace
# ↑で作業ファイルを置くディレクトリを作って、↓で持ち越されたディレクトリをアタッチしている
- attach_workspace:
at: /tmp/workspace

- setup_remote_docker:
docker_layer_caching: true

- run:
name: deploy
command: |
docker images
docker load < /tmp/workspace/docker/alpine-image.tar
docker images
workflows:
version: 2
build-and-deploy:
jobs:
- build:
filters:
branches:
only: master

- deploy:
requires:
- build
filters:
branches:
only: master
comment: 0