garicchi毎回DockerfileをGithubから取ってきてbuildしてrunするのはやっぱりイケけてないのでAWSのコンテナレジストリことECRを使ってみます。マネジメントコンソールからECRのページに行き、[リポジトリの作成]を押します。リポジトリ名は***.amazonaws.com/<名前空間>/<リポジトリ名>みたいな感じでつけれます。名前空間はなくても大丈夫なようです。リポジトリを作成できたら、イメージをpushするためにアカウント認証を行いましょう。awscliなどでインストールします。configureをしてください。loginのコマンドが表示されるだけなので必ずつけて実行しましょう。リージョンはECRのリポジトリを作ったとこにします。buildを行います。無事pushできました。無事pullできました。build時やpush時に長いリポジトリ名を書かなきゃなのは辛いですが普通に簡単に使うことができました。docker-loginをちゃんとしておくとあとはdocker-composeのimage:タグにレジストリのURLつきでイメージ名を書くと、pullしてくれるようです。logの–ancestry-pathオプションがよくわからなかったので調べて見た。9103739..e3b7b68を実行すると、以下が出力される。logに<rev1>..<rev2>とrevisionを2つのドットで繋いで範囲にすると、「<rev2>の祖先のログから<rev1>の祖先を減算したログ」を出力する。9103739..e3b7b68を実行してみよう。a8b93faと2a3c429コミットがログから消えた。–ancestry-pathをつけていない状態ではa8b93faと2a3c429があったのに、つけるとa8b93faと2a3c429が消えた。この2つのリビジョンの法則性としては2つのドットの前に指定した9103739の子孫ではないということだ。–ancestry-pathの働きは、「2つのドットの後ろにつけたリビジョンの子孫でないものを削除する」というものになる。<rev1>..<rev2>は、「<rev2>の祖先から<rev1>の祖先を削除し、さらに<rev1>の子孫でないものを削除する」意味になる。これは結果的になにをしているかというと、「<rev1>から<rev2>の間にあるコミットだけ抽出」という結果になる。slaveを起動していたのですが10数分〜1時間ぐらいで接続が切れる。コネクションが切断されました。slave側のログをみても、「terminated」としか書いてない。1週間ぐらい悩みました。fetchしたくなります。fetchしようとすると、コンテナ内との鍵の管理がめんどうになります。2パターンが考えられます。1の場合、ホストだけでなくコンテナ用の鍵をいちいち生成しなくてはならず、またGithubなどのdeploykeyに登録をしないといけなくなります。keyをリポジトリにコミットしてしまう恐れもあります。errorになってしまいます。解決策としては、マウント先は一時ファイルに.sshをマウントしておき、コンテナ実行時にコンテナのホームディレクトリにコピーすることで.sshのpermissionが正しくなります。コンテナ実行時に.sshをコピーするために、ENTRYPOINTは以下のようなシェルスクリプトにします。buildすると依存パッケージのインストールが走ります。理想的には依存パッケージに変更がなければ依存パッケージのインストールはキャッシュしたいところです。build時に依存パッケージのインストールが走ってしまいます。依存パッケージのインストールをキャッシュするためには依存パッケージを記述したファイルのみ、先にCOPYしてパッケージのインストールを行います。ソースコードはDockerfileの最後の方でCOPYします。することでソースコードに変更が合った場合、依存パッケージのインストールはキャッシュされ、ソースコードのコピーのみ処理が走ります。goの場合、depパッケージマネージャを使うならGoPkg.tomlとGoPkg.lockのみ先にコピーします。-vendor-only=trueにすることでソースコードの解析が走らずにパッケージのインストールが走ります。ensureのみで実行してしまうと、この部分がソースコードに依存してしまうのでソースコードに変更があるとパッケージの再インストールが走ってしまいます。