DockerLinux バイナリ パッケージとイメージという 2 つのよく知られた概念を使用して、継続的インテグレーションと継続的デリバリーのプロセスを実装しています。
作業の大部分はすでに完了しています。GitLabリポジトリからコードを取得し、コンパイルして、にdeb格納されているパッケージに配置しますAptly。次に、所有するすべてのサービスのイメージを作成Dockerし、イメージをプライベートDocker Registryサーバーにプッシュします。その後、これらのイメージはテスト環境にロールバックされます。最後に、サービスを開始し、受け入れテストを実行します。これは継続的なプロセスであり、誰かが にコミットをプッシュするたびに開始されorigin/masterます。
Docker レジストリに保存されている安定したイメージをどのように区別するかはまだ明らかではありません。
安定したサーバーの定期的な更新を実行する必要があるため、すべてのイメージの状態を追跡する必要があります。明らかに一部のリリース (イメージのバージョンなど) は受け入れテストに合格せず、使用不可としてマークし、継続的デリバリーの次の反復ごとに除外する必要があります。
この機能のデフォルトの実装はないようです:
- デフォルトの画像
repo/tagは、バージョン番号、ビルド日、および QA マークの両方を保持できない単純なプレーン文字列です。 Labels( 1.6で導入) は、回避策の出発点として適している可能性がありますが、既存の画像を再ラベル付けする機会を見つけることができませんでした (QA の結果を考慮して、画像の「メタデータ」を更新する必要があることに注意してください)。ラベル値で画像をクエリする方法はありませんが、おそらく Docker API をラップすることができます。
では、Docker イメージにバージョンを割り当てる適切な方法は何ですか? QA関連の情報はどのように保存できますか? 安定したイメージ ビルドを「強調表示」するにはどうすればよいですか? これらの目的を達成するために、 のどの機能をJenkins CI使用できますか? あなたの経験を共有してください。
UPD:しばらくして、Docker issue tracker でディスカッションを開始する必要がありました。おそらく誰かもそれが便利だと思うでしょう。