0

AWS で CoreOS クラスターを実行しています。AWS の各インスタンスで、docker コンテナーを実行します。たとえば、最新のソフトウェア バージョンで Docker イメージを実行する API という名前の 2 つのインスタンスがあります。

また、最新バージョンの別の Docker イメージを実行する 6 つのプロセッサ インスタンスがあります。

クラスター内のすべてのコンテナーを更新したいので、今日はパイプラインでGoCDを使用して、すべての作業を行う ansible-playbook をアクティブにします。パイプラインは github プロジェクトをリッスンし、そのブランチに変更をプッシュすると、パイプラインがアクティブになります。

API とプロセッサの新しい docker イメージを構築し、新しい更新されたイメージを dockerhub にアップロードします。次に、AWS インスタンスに接続し、アップロードしたばかりのイメージに対して docker pull を発行します。最終的に、新しくプルされたイメージでコンテナを起動します。

これは、現在、バージョンの展開を制御する方法です。

問題は次のとおりです。

  1. 長い時間がかかります
  2. さまざまな理由で失敗することがあります
  3. 柔軟性がありません（githubでリッスンしてファイルをプルするには、特定のブランチをハードコーディングする必要があります）

この仕事を成し遂げるための他の提案やツールはありますか? 場合によっては 3 台のマシンを更新する必要があり、場合によっては 7 台のマシンを更新する必要があり、スケーリングできるものが必要です。

4

2 に答える 2

1

私の環境では git を使用していませんが、Jenkins のデプロイ ワークフローを開始するコミット後の SVN フックを使用しています。Jenkins Build Pipeline Pluginを追加して、最初からやり直すのではなく、失敗から再開できるようにします。そうは言っても、GoCD がこの種のことをサポートしているかどうかを確認してください。必要がなければツールを切り替えても意味がありません。

次の変更を提案します。

  1. Ansible Playbook を展開ツールの個別のステップに分割します。これにより、障害に近づいて再起動できるため、無駄な時間が短縮されます。

  2. パイプラインに通知を設定して失敗を通知し、最後に 1 つの通知を設定して成功を通知します。プログレスバーを子守する必要はありません...すぐにイライラします

  3. ボトルネックがプロセスのどこにあるかの定量化を開始します。遅いプロセスを一度に 1 ステップずつ修正し、最初に修正するのが最も簡単なものを特定します。

于 2016-02-04T19:23:09.717 に答える
0

第 3 号以降、さまざまなブランチからコードをリリースするかどうかを検討する必要があるかもしれません。継続的デリバリー ツールである GoCD は、トランク ベースの開発、つまり常にマスターからリリースする場合に最適です。

ただし、トランクへのプッシュごとに直接本番環境にデプロイする必要はありません。Go での手動承認ステップ、または本番環境で実行されているバージョンである他のコンポーネントで実行される一連の自動テスト、またはテストと手動承認の両方を行うことができます。

問題 2 に関しては、Go Web UI のフローに従い、失敗時にメール通知を受け取り、失敗したポイントから再開できるように、GoCD でさらに多くの手順を実行することをお勧めします。

#1 については、何が遅いのか、タイミングについてどのような期待を持っているのかを教えてください。GoCD は、物事を始めるのに電光石火の速さではありません。1分に1回GITリポジトリをポーリングし、アイドル状態のエージェントが一定の間隔でサーバーにチェックインして、やるべき作業があるかどうかを確認していると思います。ただし、これは基本的に固定遅延です。インスタンスごとに GoCD ジョブを作成しない限り、アップグレードするホストが 100 台あるという理由だけで遅くなることはありません (それはおそらく良い考えではありません)。

Ansible を使用している作業には、docker compose と docker swarm の方が適しているようです。

于 2016-02-17T13:51:40.217 に答える