Downstreamジョブから情報を収集する

JenkinsにおいてジョブAから別のジョブBを呼び出した後、ジョブAの中でジョブBに関連する情報を参照したいケースがあったりしますよね。例えば、ジョブBの中でAMIを作成し、ジョブAでは作成されたAMIのami-idを知りたいとか。こんな時どうするか。

ざっくり言うと下記。 - 取得したい情報をジョブBの中で環境変数に設定する - ジョブAでは、ジョブBのジョブ情報から環境変数を取得する

下記がジョブのサンプル。 - ジョブB (呼び出される側)

node {
    stage("set env") {
        env.DOWNSTREAM_MSG = "Hello, upstream"
        echo env.DOWNSTREAM_MSG
    }
}

• ジョブA (呼び出す側)

node {
    stage('call downstream') {
        def my_job = build job: 'downstream-job', wait: true
        echo my_job.getBuildVariables().DOWNSTREAM_MSG
    }
}

• ジョブAでは、build jobを利用してジョブBを呼び出している
• このbuild stepは、RunWrapperオブジェクトを返す
• RunWrapperオブジェクトにあるgetBuildVariables()メソッドは当該ジョブ(downstreamジョブ)の中で設定された環境変数のmapを返す
• keyは環境変数名で、valueがその値
• このmapから取得する

参考

• groovy - Jenkins pipeline: return value of build step - Stack Overflow
• groovy - Jenkins pipeline: return value of build step - Stack Overflow

Pipelineから別のジョブを実行する

Jenkinsにおいて、あるジョブA(upstream)から別のジョブB(downstream)を呼ぶ方法を調べたのでメモ。 呼ばれる側のジョブB(downstream job)が下記のようなケースを考える。

• ジョブB

// 下記変数はJenkinsのパラメタとして定義してあるとする
FIRST_MESSAGE: (default/string) hello
SECOND_MESSAGE: (default/string) how are you
THIRD_MESSAGE: (default/string) good-bye


node {
    stage('print parameters') {
        print FIRST_MESSAGE
        print SECOND_MESSAGE
        print THIRD_MESSAGE
    }
}

上記のジョブを別のジョブA(upstream job)から実行したい場合、buildステップを利用する。以下、サンプル。呼び出されるジョブBの名前をprint_messageとしているケース。

• ジョブA

node {
    stage('chain job (no params)') {
        build job: 'print-message', wait: true
    }

    stage('chain job (pass params)') {
        build job: 'print-message', parameters: [
            string(name: 'FIRST_MESSAGE', value: 'This is a message from parents')
        ], wait: true
    }
}

• 1つめのbuild jobはパラメタなしでジョブを呼び出し
• 2つめのbuild jobはパラメタFIRST_MESSAGEを設定してジョブを呼び出し

参考

• 【Jenkins】パイプラインからジョブを呼び出す際、パラメータを指定する - 自分の速さで
• Jenkins pipelineコマンドメモ - Qiita

CKADを受けてみた

冬休みの宿題ということでCKADを受けてみることにした。こういう資格は初めて、かつ、最近Kubernetesに触れていなかったので、テスト対策としてお勉強。

テスト向けにやったこと

• Kubernetesの公式ドキュメントをざっと読む
  • 自信ないところ中心
• CKAD Exercisesを2周
  • kubectl run hogehoge でyamlの雛形を作ることに慣れるとよい
  • 正直なところ、これ何周もやってれば合格できると思う

昔やったこと

• 入門kubernetes読む
• 公式ドキュメントやTutorialを読む／試す

結果

• 合格できました

反省

• JobとかProbeとかLog周りを勉強しておけばよかった
  • うる覚えで調べながら進めたので時間がかかってしまった
• 当初、yamlの編集にemacs使ってたけど、ctrl-sがブラウザ側でハンドルされてしまうみたいで、コンソールが反応/表示しなくなること多数。コンソールをリセットしたり、相当時間を無駄にした。素直にvi使っておくべきだった。

gcloudコマンドでgcpに作成したインスタンスにアクセスする

直に忘れるからメモを残しておく。公式ドキュメントはこちら。

gcloudコマンドは、Google Cloud SDKの一部で、GCPのいろいろなサービスをこのコマンドで管理できる。 OpenStackにおけるopenstackコマンドみたいなもの。

インストール

gcloudコマンドはGoogle Cloud SDKの一部なので、このSDKをダウンロードし、インストールする。 fedoraの場合はyumコマンドで入れられる。

$ sudo tee -a /etc/yum.repos.d/google-cloud-sdk.repo << EOM
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
       https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOM
$ sudo dnf install google-cloud-sdk

初期化

$ gcloud init

いろいろと聞かれるので、適宜設定していく。

使ってみる

• 作成済みのインスタンスにsshでアクセスしてみる

$ gcloud compute ssh <instance名>
[hoge@instance  ~]$  

ホスト名を設定する

最近のfedoraだとhostnamectlコマンドで設定できるということを知った。

$ sudo hostname set-hostname <NEW NAME>

GCPUG Tokyo June 2018

抽選に初当選したので行ってみた。メモ。

はじめに

GCPUGについて紹介

• connpass
• 公式サイト
• nouhau
• GCP お役立ち Link集

How to utilize GKE for QA environment / @masudak (mercari)

• mercariでは、QA環境の中で1年近く前からGKEつかってるらしい。今日はそのお話。
• 発表者：@masudak
  • SET (Software Engineer in Test)
    • SETは2011年にgoogleが提唱(GoogleはSETからSETI(Software Engineer, Tools & Infrastructure)に移っているという話もある模様)
    • mercariは2016/10から導入している --> エンジニアblogに記事あり
• 開発フロー
  • PMが仕様をJIRAに書く
  • エンジニア・デザイナーがローカルで実装
  • レビュー/
  • QA環境でQAエンジニアがテスト
• QA環境
  • QAエンジニア/エンジニアがQAする環境
  • 共通のDB、検索データをもつ
  • API/Frontend/Admin/Webなどが動く
    • これらは独立してて、他の人に影響を与えないでテストできる
  • 要件
    • 自分専用/WebUIでデプロイ/スケール/可能な限り本番構成反映
• 2017春
  • 1年前くらいにmonolithic --> microservice (PHP --> Go)
  • CircleCIの中でデプロイ
    • CircleCIのなかでごにょごにょ
    • PR番号とってきてk8s.yaml(テンプレ)の中の変数をsedで置き換え
    • 外部からのアクセスはリバプロ(Goで実装)でhttp header見て適切なPodにrouting
    • わりと地道なことをやってたみたい(Pod消す時とか)
  • 力技 --> めんてつらい
• 2017後半
  • Spinnaker
    • CircleCIからはGCRにイメージをpush
    • それをトリガにSpinnakerがデプロイ(pollingしてるらしい)
    • WebUI中心で微妙
    • PR Podsに対応できない = PRごとの環境が作れない
  • CRDを作成(k8sのreconciliation loopを利用）
    • k8s controller for PR
      • ループしてPRの状況を確認する
      • Openだったら既存のRSを複製
      • 環境変数などを書き換え
      • desired stateを書き換え
      • PRのRS完成
      • ひつように応じてexternal-dnsでドメイン付与
      • ---> ひょっとしてkustomizeで置き換え可能かも
• まとめ
  • 開発生産性も品質もまだ追求できる
  • たった１つのVM時代(virtualenvとか使って環境分離？？)から2年でここまできた
• Q&A
  • databaseとかのスキーマ変わるような場合のテストはどうするのか?
    • API gatewayの開発の話なので、DBのスキーマが変わるような変更には対応していない
  • SETの役割
    • テストのやり方とか、こうテストするといいよとか考えているの?
    • CaosEngineeringとか考えているけど、チームとしてはまだ取り組めていない
    • SETは４人

GCPの新機能の話もあったけど、App Engineはちゃんとつかっていないので、メモはなし ;p

感想

• SETというroleを作り、QAにもちゃんとコストかけて改善しているのは良いというか羨ましいですね。
• CircleCIのながでごにょごにょの部分が今ひとつ何やってるかわからず。PRごとにReplicaSet作ってデプロイしているのかな。そのうち資料が公開されたら改めて確認する。
• ここでもCRDだった。やはりCRD化(k8s Native化)が流れなの?
• マイクロサービス化に取り組んでいるのここ1年ぐらいなんですね。もっと前からやっているのかと勝手に思ってた。
• たった１つのVM時代とはどんな感じでQA環境として使っていたのか気になった。
• 開発はローカルでやっているみたいだけど、やはり開発はローカルでやるのが普通なのかな。GKE上とかでやらないのか気になった。

kubeadmで構築した環境のkube-apiserverを再起動する

kube-apiserverを設定変更して再起動したくなったのだけど、 kubeadmでデプロイした場合どうするのか知らなかったので調べた結果をメモ。

まあ、全く同じ質問がstack overflowにあったので、それを読めば良いです。

まとめると下記。

• kubeadmはkube-apiserverをstatic Podとしてデプロイする
• static Podとは
  • kubeletが直接管理しているPodで、Podがcrashとかするとkubeletが勝手に再起動したりしてくれる
  • apiサーバからは"mirror pod"が見えるけど、apiサーバ経由で操作することは不可能
• そのため、kube-apiserverを再起動したい場合、kube-apiserverが動いているホストに ログインしてdockerコマンドでコンテナを止める
• するとkubeletが再起動してくれる

ちなみに、kube-apiserverのmanifestはcentosの場合、/etc/kubernetes/manifestsにあるので、設定を変更する場合はこれを修正する。 (ちゃんと確認していないけど、設定変更したらkubeletがそれを検知してくれてコンテナ再起動するかも --> 今度調べる)

参考

• Restart kube-apiserver when provisioned with kubeadm
• Static Pods