プラグイン、SMS、登録なしでGKEに展開するタスクをマスターします。ジェンキンスのジャケットの下を片目で覗く

それはすべて、開発チームの1つのチームリーダーがテストモードで、前日にコンテナ化された新しいアプリケーションを公開するように依頼したという事実から始まりました。我慢しました。約20分後、非常に必要な部分が完成したため、アプリケーションの更新要求を受け取りました。更新しました。さらに数時間後...まあ、あなたは



すでに次に何が起こり始めたかを推測します...私は認めなければなりません、私はかなり怠惰です（私はこれを以前に認めましたか？いいえ？）そして、チームリーダーがジェンキンスにアクセスできるという事実を考えると、私たちはすべてのCI / CDを持っていると思いました：彼に好きなだけ自分自身を展開させてください！私は逸話を思い出しました：男に魚を与えると、彼はその日は満腹になります。満腹の人を呼ぶと、彼は一生満腹になります。そして彼は仕事で遊びに行きました、正常に組み立てられたバージョンを適用してコンテナを展開し、ENV値を転送することができます（私の祖父、哲学者、過去の英語の教師は、これを読んだ後、彼の寺院で指をひねり、私を非常に表現力豊かに見ます文）。



それで、投稿で私がどのように学んだかについて話します：

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

実際、私はもちろん少し狡猾です。所有しているインフラストラクチャの少なくとも一部がGoogleクラウドにあると想定されているため、ユーザーはそのユーザーであり、もちろんGCPアカウントを持っています。しかし、メモはそれについてではありません。



これは私の次のチートシートです。そのようなメモを書きたいのは1つの場合だけです。以前に問題が発生し、最初は解決方法がわからず、解決策が完成した形でグーグルされていなかったため、部分的にグーグルで検索し、最終的に問題を解決しました。そして、将来、自分のやり方を忘れたときに、すべてをもう一度グーグルで検索してまとめる必要がないように、自分でそのようなチートシートを作成します。

Disclaimer: 1. « », best practice . « » .

2. , , , — .

Jenkins

私はあなたの質問を予見します：動的な仕事の更新はそれと何の関係がありますか？文字列パラメータの値をハンドルで入力して先に進みます！



答えは：私は本当に怠け者です、彼らが不平を言うとき、私はそれが好きではありません：ミーシャ、展開はクラッシュしています、すべてがなくなっています！あなたは探し始めます、そしていくつかのタスク起動パラメータの値にタイプミスがあります。したがって、私は可能な限り完全にすべてを行うことを好みます。代わりに選択する値のリストを指定することで、ユーザーがデータを直接入力できないようにすることが可能な場合は、選択を整理します。



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



Jenkinsでジョブを作成および構成するプロセスについては考慮しません。これは、トピックから外れています。タスクの準備ができていると想定します。更新可能なバージョンリストを実装するには、2つのものが必要です。事前に有効なバージョン番号を持つ既存のソースリストと、タスク内のChoiceパラメータタイプの変数です。この例では、変数の名前をBUILD_VERSIONとします。これについては、詳しく説明しません。しかし、ソースリストを詳しく見てみましょう。



それほど多くのオプションはありません。2つはすぐに私に起こりました：

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

JenkinsリモートアクセスAPI

確立された素晴らしい伝統によれば、私は長い説明を避けたいと思います。APIドキュメントの最初のページの

最初の段落の一部のみを自由に翻訳することを許可します。

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

つまり、現在話している展開タスクがアドレスhttp://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_buildで利用できる場合、このタスクのAPIホイッスルは 次で利用できます。出力を受信する形式を選択できます。この場合、APIはフィルタリングのみを許可するため、XMLについて詳しく見ていきましょう。 すべてのジョブ実行のリストを取得してみましょう。アセンブリ名（displayName）とその結果（result）のみに関心があります。http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/

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

起こりました？



ここで、SUCCESSの結果になる起動のみを除外してみましょう。＆exclude引数を使用し、パラメーターとしてSUCCESSに等しくない値へのパスを渡します。はいはい。二重否定は声明です。興味のないものはすべて除外します。

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']

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

バージョンのリストを取得する2番目の方法もあります。JenkinsAPI呼び出しよりもさらに気に入っています。アプリケーションが正常にビルドされた場合は、パッケージ化されて、リポジトリの適切なフォルダに配置されているためです。同様に、リポジトリはデフォルトでアプリケーションの動作バージョンのリポジトリです。お気に入り。さて、どのバージョンがストレージにあるかを彼に聞いてみましょう。リモートフォルダをcurl、grep、awkします。誰かがアンライナーに興味があるなら、それはスポイラーの下にあります。

Jenkinsのジョブセットアップおよびジョブ構成ファイル

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



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



そして今、楽しい部分。 Jenkinsはジョブ構成をファイルに保存します。 XML形式。途中でhttp://--/config.xmlしたがって、構成ファイルをダウンロードし、必要に応じて編集して、元の場所に配置することができます。



上記で、バージョンリストのBUILD_VERSIONパラメータを作成することに同意したことを覚えていますか？



設定ファイルをダウンロードして、その中を見てみましょう。パラメータが適切に配置され、本当に正しい種類であることを確認するためだけに。



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





あなたは確信していますか？さて、ビルドが成功した場合に実行されるスクリプトを作成しています。

スクリプトはバージョンのリストを受け取り、構成ファイルをダウンロードし、必要な場所にバージョンのリストを書き込んでから、元に戻します。はい。すべてが正しいです。バージョンのリストがすでにある場所にXMLでバージョンのリストを書き込みます（将来、スクリプトの最初の起動後になります）。世界にはまだ定期的な表現を愛する人がいることを私は知っています。私は彼らのものではありません。設定を編集するマシンにxmlstarlerをインストールしてください。これは、sedを使用したXML編集を回避するために支払う大きな代償ではないように思われます。



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





Jenkinsからバージョンを取得するオプションが好きで、私と同じくらい怠惰な場合は、スポイラーの下で同じコードを使用しますが、リストはJenkinsからのものです。





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





すべてが機能した場合は、スクリプトをコピーして[シェルの実行]コマンドに貼り付け、変更を保存します。

クラウドシェル接続

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



「箱から出して」コンテナをクラウドコンソールで組み立てることができるので、なぜ野菜園をフェンスで囲うのでしょうか。清潔に保ってくださいね？クラウドコンソールでJenkinsを使用してコンテナを作成し、そこからKuberに撃ち込みたいと思います。さらに、インフラストラクチャ内には、Googleには非常に太いチャネルがあり、展開の速度に有益な効果をもたらします。



クラウドコンソールに接続するには、次の2つが必要です。gcloudアクセス権をGoogleクラウドAPIこの接続が行われます、そこからVMインスタンスの。





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

1. 将来、クラウドコンソールに接続するVMインスタンスを停止します。
2. インスタンスの詳細を開き、[編集]をクリックします。
3. ページの一番下で、インスタンスアクセススコープを選択します。すべてのCloudAPIへのフルアクセス。
   
   
   
   
   スクリーンショット

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

VMの起動が完了したら、SSH経由でVMに接続し、接続が成功することを確認します。次のコマンドを使用します。

gcloud alpha cloud-shell ssh

GKEにデプロイする

IaC（Infrastucture as a Code）に完全に切り替えるためにあらゆる方法で努力しているため、dockerfileをgitaに保存します。これは一方でです。kubernetesでの展開は、yamlファイルによって記述されます。このファイルは、このタスクでのみ使用され、それ自体もコードのようなものです。これは反対側にあります。一般的に、私は計画が次のとおりであることを意味します：

1. BUILD_VERSION変数の値を取得し、オプションで、ENVを介して渡される変数の値を取得します。
2. gitaからdockerfileをダウンロードしています。
3. 展開用のyamlを生成しています。
4. これらのファイルの両方をscp経由でクラウドコンソールにアップロードします。
5. そこでコンテナを作成し、コンテナレジストリにプッシュします
6. ロードデプロイメントファイルをKuberに適用します。

もっと具体的にしましょう。ENVについて話しているので、PARAM1とPARAM2の2つのパラメーターの値を渡す必要があるとしましょう。-展開、タイプのために自分のタスクを追加します文字列パラメータ。





echoをファイルに リダイレクトするだけでyamlを生成します。もちろん、dockerfileにPARAM1とPARAM2があり、ロード名はawesomeappであり、指定されたバージョンのアプリケーションでアセンブルされたコンテナーは、パスgcr.io/awesomeapp/awesomeapp- $ BUILD_VERSIONに沿ったコンテナーレジストリにあると想定されます。ここで、$ BUILD_VERSIONはちょうどです。ドロップダウンリストから選択されました。





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



古い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-cluster）と、クラスターが配置されているプロジェクトの名前（awesome-project）を使用していることに注意してください。

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"

タスクを開始し、コンソール出力を開いて、コンテナーが正常にビルドされることを確認します。





そして、組み立てられたコンテナの展開の成功





Ingressの 設定を意図的に無視しました。単純な理由の1つは、特定の名前のワークロード用に構成すると、この名前のデプロイメントがいくつ実行されても、操作可能なままになります。まあ、一般的に、これは歴史の範囲を少し超えています。

結論の代わりに

上記のすべての手順は、おそらく実行できなかった可能性がありますが、Jenkinsのmuuulion用のプラグインをインストールするだけでした。しかし、どういうわけか私はプラグインが好きではありません。まあ、もっと正確に言えば、私は絶望からだけ彼らに頼ります。



そして、私は私のためにいくつかの新しいトピックを取り上げるのが好きです。上記のテキストは、私が行った調査結果を共有する方法でもあり、最初に説明した問題を解決します。のように、devopsの悲惨なオオカミではない人々と共有してください。私の発見が少なくとも誰かを助けるなら、私は幸せになるでしょう。