プラグイン、SMS、登録を使用せずに、GKE でデプロイ タスクを作成します。 ジェンキンスのジャケットの下を覗いてみましょう

すべては、開発チームの 20 つのチームリーダーが、前日にコンテナ化された新しいアプリケーションをテストするように私たちに依頼したときに始まりました。 投稿しました。 XNUMX分ほど後、非常に必要なものが追加されていたため、アプリケーションを更新するように要求されました。 リニューアルしました。 さらに数時間後...まあ、次に何が起こり始めたかは想像できるでしょう...

正直に言うと、私はかなり怠け者です (これを以前に認めませんでしたか? いいえ?)。チーム リーダーがすべての CI/CD を持っている Jenkins にアクセスできるという事実を考慮して、彼に次のようにデプロイさせようと思いました。彼が望むだけ！ 私はジョークを思い出しました。「人に魚を一匹与えれば、一日食べられるでしょう。」 ある人を「Fed」と呼ぶと、その人は一生Fedされることになる。 そして、行ってきました 仕事中にいたずらをするこれにより、正常に構築されたバージョンのアプリケーションを含むコンテナを Kuber にデプロイし、それに任意の値を転送できるようになります。 ENV （私の祖父は文献学者で、昔は英語の教師でしたが、今ではこの文を読んだ後、こめかみで指を回し、非常に表情豊かに私を見つめていました）。

そこで、このメモでは、私がどのように学んだかを説明します。

1. Jenkins でジョブ自体または他のジョブからジョブを動的に更新します。
2. Jenkins エージェントがインストールされているノードからクラウド コンソール (Cloud Shell) に接続します。
3. ワークロードを Google Kubernetes Engine にデプロイします。

実際のところ、もちろん私は多少不誠実なところもあります。 インフラストラクチャの少なくとも一部が Google クラウドにあることを前提としています。したがって、あなたはそのユーザーであり、当然 GCP アカウントを持っています。 しかし、それはこのメモの内容ではありません。

これが次回のチートシートです。 私はそのようなメモをXNUMXつのケースでのみ書きたいと思います。問題に直面しましたが、最初はそれを解決する方法がわかりませんでした。解決策は既製のものではなく、Googleで検索したため、部分的にGoogleで検索し、最終的に問題を解決しました。 そして、将来、どのようにやったかを忘れたときに、すべてをもう一度グーグルで調べてまとめてまとめる必要がなくなるように、そのようなカンニングペーパーを自分で書きます。

免責事項： 1. そのメモは「自分のため」、役のために書かれた ベストプラクティス 適用されません。 コメントで「こうしたほうがよかった」という選択肢を読んでうれしく思います。
2. ノートの適用部分が塩であるとみなされる場合、これまでのすべてのノートと同様、これは弱い塩溶液です。

Jenkins でのジョブ設定の動的更新

あなたの質問は予想通りです: 動的ジョブ更新はそれとどのような関係があるのですか? 文字列パラメータの値を手動で入力すると、作業が始まります。

私は答えます：私は本当に怠け者です、彼らが文句を言うのは好きではありません：ミーシャ、デプロイメントがクラッシュしています、すべてが消えています！ 調べ始めると、タスク起動パラメータの値にタイプミスがありました。 したがって、私はすべてをできるだけ効率的に行うことを好みます。 代わりに選択できる値のリストを提供することで、ユーザーがデータを直接入力できないようにできる場合は、選択内容を整理します。

計画は次のとおりです。Jenkins でジョブを作成します。ジョブを起動する前に、リストからバージョンを選択し、コンテナーに渡されるパラメーターの値を指定します。 ENV、次に、コンテナーを収集し、それをコンテナー レジストリにプッシュします。 次に、そこからコンテナが cuber で次のように起動されます。 ワークロード ジョブで指定されたパラメータを使用します。

Jenkins でジョブを作成して設定するプロセスについては考慮しません。これは本題から外れます。 タスクの準備ができていると仮定します。 バージョンを含む更新されたリストを実装するには、事前に有効なバージョン番号を含む既存のソース リストと次のような変数の XNUMX つが必要です。 選択パラメータ タスクの中で。 この例では、変数に次の名前を付けます。 ビルド_バージョン、これについては詳しく説明しません。 しかし、ソースリストを詳しく見てみましょう。

選択肢はそれほど多くありません。 すぐに次の XNUMX つのことが思い浮かびました。

• Jenkins がユーザーに提供するリモート アクセス API を使用します。
• リモート リポジトリ フォルダーのコンテンツをリクエストします (この場合、これは JFrog Artifactory ですが、これは重要ではありません)。

Jenkins リモート アクセス API

確立された優れた伝統に従って、長々とした説明は避けたいと思います。
最初の段落の一部のみを自由に翻訳することを許可します API ドキュメントの最初のページ:

Jenkins は、その機能へのリモートの機械読み取り可能なアクセスのための API を提供します。 <…> リモート アクセスは REST のようなスタイルで提供されます。 これは、すべての機能への単一のエントリ ポイントはなく、代わりに「」のような URL が存在することを意味します。.../api/"、 どこ "..." は、API 機能が適用されるオブジェクトを意味します。

言い換えれば、現在話している展開タスクが次の場所で利用できる場合、 http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_buildの場合、このタスクの API ホイッスルは次の場所から入手できます。 http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/

次に、出力をどの形式で受け取るかを選択します。 この場合、API ではフィルタリングのみが許可されるため、XML に焦点を当てましょう。

すべてのジョブ実行のリストを取得してみましょう。 アセンブリ名のみに関心があります (displayName) とその結果 (結果):

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]

それは動作しましたか？

次に、結果が得られる実行のみをフィルタリングしましょう 成功。 引数を使ってみましょう 除外(&X) そしてパラメータとして、等しくない値へのパスを渡します。 成功。 はいはい。 二重否定はステートメントです。 興味のないものはすべて除外します。

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!='SUCCESS']

成功したリストのスクリーンショット

そうですね、楽しみのために、フィルターが私たちを欺いていないことを確認して (フィルターは決して嘘をつきません!)、「失敗した」フィルターのリストを表示してみましょう。

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result='SUCCESS']

失敗したもののリストのスクリーンショット

リモートサーバー上のフォルダーからのバージョンのリスト

バージョンのリストを取得する XNUMX 番目の方法があります。 私は Jenkins API にアクセスするよりもこの方法の方が好きです。 アプリケーションが正常に構築されたということは、アプリケーションがパッケージ化され、適切なフォルダーのリポジトリに配置されたことを意味するためです。 同様に、リポジトリはアプリケーションの動作バージョンのデフォルトのストレージです。 のように。 では、ストレージにどのバージョンがあるのか​​聞いてみましょう。 リモート フォルダーに対して、curl、grep、および awk を実行します。 ワンライナーに興味がある人は、スポイラーの下にあります。

一行コマンド
XNUMX つのことに注意してください。ヘッダーで接続の詳細を渡します。フォルダー内のすべてのバージョンは必要なく、XNUMX か月以内に作成されたバージョンのみを選択します。 現実とニーズに合わせてコマンドを編集します。

curl -H "X-JFrog-Art-Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )

Jenkins でのジョブとジョブ構成ファイルのセットアップ

バージョンのリストのソースを特定しました。 結果のリストをタスクに組み込みましょう。 私にとって、明らかな解決策は、アプリケーションのビルド タスクにステップを追加することでした。 結果が「成功」の場合に実行されるステップ。

アセンブリ タスクの設定を開き、一番下までスクロールします。 次のボタンをクリックします。 ビルドステップの追加 -> 条件付きステップ（単一）。 ステップ設定で条件を選択します 現在のビルドステータス、値を設定します 成功、成功した場合に実行されるアクション シェルコマンドを実行する.

ここからが楽しいところです。 Jenkins はジョブ構成をファイルに保存します。 XML 形式。 途中で http://путь-до-задания/config.xml したがって、構成ファイルをダウンロードし、必要に応じて編集し、入手した場所に戻すことができます。

バージョンのリストのパラメータを作成することに上記で同意したことを思い出してください。 ビルド_バージョン?

構成ファイルをダウンロードして、その中身を見てみましょう。 パラメーターが適切に配置され、目的のタイプであることを確認するためです。

スポイラーの下のスクリーンショット。

config.xml フラグメントは同じように見えるはずです。 ただし、choices 要素の内容がまだ欠落しています。

本気ですか？ これで、ビルドが成功した場合に実行されるスクリプトを作成しましょう。
スクリプトはバージョンのリストを受け取り、構成ファイルをダウンロードし、必要な場所にバージョンのリストを書き込み、それを元に戻します。 はい。 それは正しい。 バージョンのリストが既に存在する場所 (将来、スクリプトの最初の起動後に追加されます) に、XML でバージョンのリストを書き込みます。 世界には正規表現の熱烈なファンがまだいることを私は知っています。 私は彼らに属していません。 インストールしてください xmlスターラー 構成を編集するマシンにコピーします。 sed を使用した XML の編集を避けるために支払う代償は、それほど大きなものではないと思われます。

スポイラーの下に、上記のシーケンス全体を実行するコードを示します。

リモートサーバー上のフォルダーからバージョンのリストを構成ファイルに書き込みます

#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml

############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml

xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml

xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml

############## Читаем в массив список версий из репозитория
readarray -t vers < <( curl -H "X-JFrog-Art-Api:Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )

############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r | 
                while IFS= read -r line
                do
                    xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
                done

############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml

############## Приводим рабочее место в порядок
rm -f appConfig.xml

Jenkins からバージョンを取得するオプションを好み、私と同じくらい怠け者である場合は、スポイラーの下に同じコードがありますが、Jenkins からのリストが表示されます。

Jenkins からのバージョンのリストを構成に書き込みます
この点に注意してください。アセンブリ名は、コロンで区切られたシーケンス番号とバージョン番号で構成されます。 したがって、awk は不要な部分を切り捨てます。 自分自身のニーズに合わせてこの行を変更してください。

#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml

############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml

xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml

xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml

############## Пишем в файл список версий из Jenkins
curl -g -X GET -u username:apiKey 'http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!=%22SUCCESS%22]&pretty=true' -o builds.xml

############## Читаем в массив список версий из XML
readarray vers < <(xmlstarlet sel -t -v "freeStyleProject/allBuild/displayName" builds.xml | awk -F":" '{print $2}')

############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r | 
                while IFS= read -r line
                do
                    xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
                done

############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml

############## Приводим рабочее место в порядок
rm -f appConfig.xml

理論的には、上記の例に基づいて記述されたコードをテストした場合、展開タスクにはバージョンを含むドロップダウン リストがすでに存在しているはずです。 スポイラーの下のスクリーンショットのような感じです。

正しく完成したバージョンのリスト

すべてがうまくいった場合は、スクリプトをコピーして貼り付けます。 シェルコマンドを実行する そして変更を保存します。

クラウドシェルへの接続

コンテナにコレクターがいます。 当社では、アプリケーション配信ツールおよび構成マネージャーとして Ansible を使用しています。 したがって、コンテナーを構築する場合、Docker を Docker にインストールする、Ansible を実行しているマシンに Docker をインストールする、またはクラウド コンソールでコンテナーを構築するという XNUMX つのオプションが思い浮かびます。 この記事では Jenkins のプラグインについては沈黙することに同意しました。 覚えて？

私は次のように判断しました。「すぐに使える」コンテナーはクラウド コンソールで収集できるのですから、わざわざ行う必要はありません。 きれいにしておいてくださいね？ クラウド コンソールで Jenkins コンテナを収集し、そこから cuber で起動したいと考えています。 さらに、Google のインフラストラクチャ内には非常に豊富なチャネルがあり、展開の速度に有益な効果をもたらします。

クラウド コンソールに接続するには、次の XNUMX つのものが必要です。 gクラウド およびアクセス権 GoogleクラウドAPI これと同じ接続が確立される VM インスタンスの場合。

Google Cloud 以外から接続する予定がある方へ
Google は、そのサービスで対話型認証を無効にする可能性を許可しています。 これにより、*nix を実行していてコンソール自体がある場合は、コーヒーマシンからでもコンソールに接続できるようになります。

このメモの枠組みの中でこの問題をさらに詳しく説明する必要がある場合は、コメントに書いてください。 十分な票が集まったら、このトピックについて最新情報を書きます。

権利を付与する最も簡単な方法は、Web インターフェイスを使用することです。

1. 後でクラウド コンソールに接続する VM インスタンスを停止します。
2. 「インスタンスの詳細」を開き、「インスタンスの詳細」をクリックします。 修正します.
3. ページの一番下で、インスタンスのアクセス範囲を選択します すべてのクラウド API へのフルアクセス.

   スクリーンショット
   

4. 変更を保存し、インスタンスを起動します。

VM の読み込みが完了したら、SSH 経由で VM に接続し、エラーなく接続が行われることを確認します。 次のコマンドを使用します。

gcloud alpha cloud-shell ssh

成功した接続は次のようになります

GKE へのデプロイ

私たちはあらゆる方法で IaC (Infrastucture as a Code) への完全な移行に取り組んでいるため、Docker ファイルは Git に保存されています。 これは一方では。 また、kubernetes でのデプロイメントは、このタスクでのみ使用される yaml ファイルによって記述され、それ自体もコードのようなものです。 これは反対側からです。 つまり、大まかに言うと、計画は次のとおりです。

1. 変数の値を取得します ビルド_バージョン およびオプションで、渡される変数の値 ENV.
2. Git から dockerfile をダウンロードします。
3. デプロイメント用の yaml を生成します。
4. これらのファイルは両方とも scp 経由でクラウド コンソールにアップロードします。
5. そこでコンテナを構築し、コンテナ レジストリにプッシュします。
6. ロードデプロイメントファイルを cuber に適用します。

もっと具体的に言ってみましょう。 について話し始めると、 ENV次に、XNUMX つのパラメータの値を渡す必要があるとします。 パラメータ1 и パラメータ2。 デプロイメント用のタスクを追加します。「-」と入力します。 文字列パラメータ.

スクリーンショット

単純なリダイレクトを使用して yaml を生成します echo ファイルへ。 もちろん、dockerfile に次のものがあることを前提としています。 パラメータ1 и パラメータ2ロード名は次のようになります 素晴らしいアプリ、指定されたバージョンのアプリケーションを使用して組み立てられたコンテナーは次の場所にあります。 コンテナレジストリ 途中で gcr.io/awesomeapp/awesomeapp-$BUILD_VERSIONどこ $BUILD_VERSION ドロップダウン リストから選択されたばかりです。

チームリスト

touch deploy.yaml
echo "apiVersion: apps/v1" >> deploy.yaml
echo "kind: Deployment" >> deploy.yaml
echo "metadata:" >> deploy.yaml
echo "  name: awesomeapp" >> deploy.yaml
echo "spec:" >> deploy.yaml
echo "  replicas: 1" >> deploy.yaml
echo "  selector:" >> deploy.yaml
echo "    matchLabels:" >> deploy.yaml
echo "      run: awesomeapp" >> deploy.yaml
echo "  template:" >> deploy.yaml
echo "    metadata:" >> deploy.yaml
echo "      labels:" >> deploy.yaml
echo "        run: awesomeapp" >> deploy.yaml
echo "    spec:" >> deploy.yaml
echo "      containers:" >> deploy.yaml
echo "      - name: awesomeapp" >> deploy.yaml
echo "        image: gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION:latest" >> deploy.yaml
echo "        env:" >> deploy.yaml
echo "        - name: PARAM1" >> deploy.yaml
echo "          value: $PARAM1" >> deploy.yaml
echo "        - name: PARAM2" >> deploy.yaml
echo "          value: $PARAM2" >> deploy.yaml

を使用して接続した後の Jenkins エージェント gcloud alpha クラウドシェル ssh インタラクティブ モードは利用できないため、パラメータを使用してコマンドをクラウド コンソールに送信します。 - 指示.

クラウド コンソールのホーム フォルダーを古い dockerfile から削除します。

gcloud alpha cloud-shell ssh --command="rm -f Dockerfile"

scp を使用して、新しくダウンロードした dockerfile をクラウド コンソールのホーム フォルダーに配置します。

gcloud alpha cloud-shell scp localhost:./Dockerfile cloudshell:~

コンテナを収集し、タグ付けして、コンテナ レジストリにプッシュします。

gcloud alpha cloud-shell ssh --command="docker build -t awesomeapp-$BUILD_VERSION ./ --build-arg BUILD_VERSION=$BUILD_VERSION --no-cache"
gcloud alpha cloud-shell ssh --command="docker tag awesomeapp-$BUILD_VERSION gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"
gcloud alpha cloud-shell ssh --command="docker push gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"

デプロイメント ファイルでも同じことを行います。 以下のコマンドでは、デプロイメントが行われるクラスターの架空の名前が使用されていることに注意してください (awsmクラスター) とプロジェクト名 (素晴らしいプロジェクト)、クラスターが配置されている場所。

gcloud alpha cloud-shell ssh --command="rm -f deploy.yaml"
gcloud alpha cloud-shell scp localhost:./deploy.yaml cloudshell:~
gcloud alpha cloud-shell ssh --command="gcloud container clusters get-credentials awsm-cluster --zone us-central1-c --project awesome-project && 
kubectl apply -f deploy.yaml"

タスクを実行し、コンソール出力を開き、コンテナーのアセンブリが成功することを期待します。

スクリーンショット

そして、組み立てられたコンテナのデプロイが成功します。

スクリーンショット

意図的に設定を無視した 進入。 単純な理由は XNUMX つあります。一度セットアップすると、 ワークロード 指定した名前を使用すると、この名前でデプロイメントを何回実行しても、動作し続けます。 まあ、一般的に、これは歴史の範囲を少し超えています。

結論の代わりに

上記のすべての手順はおそらく実行できず、Jenkins の機能である Jenkins 用のプラグインをインストールするだけで済みました。 しかし、どういうわけか私はプラグインが好きではありません。 そうですね、より正確に言えば、私は絶望的な気持ちからそれらに頼っているだけです。

そして、私は自分にとって新しいトピックを取り上げたいと思っています。 上記のテキストは、最初に説明した問題を解決する際に得た発見を共有する方法でもあります。 彼のように、Devops においてまったくダイアウルフではない人々と共有してください。 私の調査結果が少なくとも誰かの役に立てば幸いです。

出所： habr.com