SRE Next 2020 に参加してきた #srenext

はじめに

公式リンクは以下。
sre-next.dev

参加したセッション

【早期来場者特典】SRE NEXT 特別ヨガプログラム

オープニング前にヨガがデリバリされていた。

ヨガしている間は Tweet するのもったいなかったので集中して取り組んでた。
ヨガ初体験。

大満足。

[A0] 分散アプリケーションの信頼性観測技術に関する研究

speakerdeck.com

まさに SRE の "Next" で、どういう分野に課題があって研究が進められているか、という話が中心。
興味深い内容だった。

[A1] 40000 コンテナを動かす SRE チームに至るまでの道

技術的な情報はこちらの記事参照とのこと。

techblog.yahoo.co.jp

[B2] 計画的に負荷リスクを排除するためのキャパシティプランニング

[D3] Practices for Making Alerts Actionable

休憩

[C5] スクラムを1年回してSREと開発組織がどう変わったのか

おわりに

ここまででセッションはほぼ半分だが、力尽きて途中退場した。

WillPowerの上限増やしたい。

IIJmio ひかり IPoE をはじめた

はじめに

こんなニュースが飛び込んできたので、ちょっと調べて対応した。

結果

経過

事前に少し調査してた。

だいたいよさそうなので申し込んだ。

2020/01/20 22:59 申し込み。

2020/01/22 21:31時点で IPv6 確認。48時間以内。早い。

おわりに

Togetter 的な雑記事。

NEC Aterm WG1200HS2 PA-WG1200HS2

NEC Aterm WG1200HS2 PA-WG1200HS2

  • 発売日: 2017/06/08
  • メディア: エレクトロニクス

GitHub Actions に Install azcopy v1 をリリースした

はじめに

前記事でも書いたが、GitHub Actions を使い始めた。

kheiakiyama.hateblo.jp

GitHub Actions(と Azure Pipelines) は Travis CI などと比べて Action という単位で抽象化できるのがメリットだと考えている。
自分がよく使うスクリプトを毎回書くのは嫌なのでどうにかしたいと考えたところ、オリジナルの Action をリリースできるとわかったのでカッとなって作った。
Action は以下。

github.com

この Action についてはこの記事では触れない。
詳細は上のリンクや GitHub リポジトリを参照のこと。

GitHub Actions の作り方

公式に丁寧なドキュメントが用意されているのでそちらを参照。

help.github.com

今回は「JavaScript アクション」で実装した。

コード自体は TypeScript で書くためのテンプレートリポジトリが公式から提供されているので、それをベースに作成した。

github.com

というか Template という GitHub の機能使ったの初めてだった。便利。

所感

リリースがすごく簡単でよい

GitHub リポジトリ上のリリース機能でチェックをつけるだけでリリースできる。
リリース後もチェックを外すだけで簡単に取り下げることができる。(もちろん既に利用者がいれば影響するわけだが)

GitHub Marketplaceでのアクションの公開 - GitHub ヘルプ

namespace の良し悪し

今回の Action でいえば - uses: kheiakiyama/install-azcopy-action@v1 のように指定する。
これはその Action の GitHub 上のユーザ名 + リポジトリ名である。

そのため npm や gem などパッケージ管理で起きがちな名前取得競争が発生しない。
その代わりにリポジトリ名に "action" をつけるべきか迷うことになった。
yaml を書くユーザ側からすれば "action" は不要なのだが、個人のリポジトリとしては識別できるようにつけておきたい。
書く側のエゴでつけることとした。

Category を選びづらい

Publish するときに以下のような画面から Category を選ぶ。

GitHub Actions publish category

以下の Action 検索画面を見るとわかるが、何かをインストールする Action に当てはまるちょうどいい Category がない。 GitHub Marketplace · Actions to improve your workflow · GitHub

GitHub Actions は WindowsUbuntu, Mac などのほぼバニラな環境からワークフローを組む特性上、何かのツールをインストールすることが多いきがするのだが、それに当てはまる Category がないのは厳しい。
最終的に苦し紛れに "Utilities" を選ぶことになった。

action.yml の branding プレビューが欲しい

branding:
  icon: 'triangle'  
  color: 'blue'

Marketplace 上での見た目を上記のようにメタデータで定義する。
これが残念ながらリリースしてみないとわからない。 以下のように内容ではなくプレビューが出てくると嬉しい。

GitHub Actions publish action.yml

GitHub Actionsのメタデータ構文 - GitHub ヘルプ

さいごに

OSS として公開しているので、問題が起きないように管理していきたい。
バグ報告や要望お待ちしています。

github.com

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Azure Blob Storage を使った Static website を GitHub Actions でデプロイする

はじめに

しばらく前に作った以下のレジュメサイトの DevOps を Travis CI から GitHub Actions に引っ越した。

cv.kheiakiyama.com

理由としては GitHub Actions を実用したかったためだ。

GitHub Actions のバックエンドが Azure Pipelines の fork 版

新 GitHub Actions 入門 - 生産性向上ブログ

と聞いていた背景と、普段 Azure Pipelines を利用している立場からも GitHub Actions との違いを知りたかった。

Travis CI で構成したときの記事は以下。
kheiakiyama.hateblo.jp

GitHub Actions のドキュメント

ドキュメントは日本語で用意されている。

help.github.com

ただ、Azure Pipelines を知っているせいか、「Artifact」 が「成果物」となっているなど、違和感が多々あり、英語のドキュメントを読むほうがしっくりくるかもしれない。

help.github.com

それにしても Azure Pipelines のドキュメントは英語のみなのに GitHub Actions は違うんですね。。

↓ Azure Pipelines のドキュメント
Azure Pipelines documentation | Microsoft Docs

GitHub Actions での実装

現物は GitHub 上のリンク を参照してもらうとして、定義ファイルの yaml に解説を追記しておく。

name: "release"
on: # rebuild master branch changes
  push:
    branches:
      - master

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2 # 利用する GitHub Actions を ダウンロードするための処理
    - uses: actions/setup-ruby@v1 # jekyll で使う ruby のインストール用 GitHub Action
      with:
        ruby-version: 2.5
    - name: Set up bundler
      run: gem install bundler
    - name: nokogiri dependencies # bundle install で nokogiri を正しくインストールするための依存ライブラリのインストール
      run: |
        sudo apt-get update
        sudo apt-get install libxml2 libxslt1-dev
    - name: jekyll build
      run: |
        bundle install --jobs 4
        ./scripts/cibuild
      env:
        NOKOGIRI_USE_SYSTEM_LIBRARIES: false
    - name: Upload jekyll output # Azure DevOps ではおなじみの Artifact にアップロード、次の Job に受け渡す
      uses: actions/upload-artifact@v1
      with:
        name: jekyll
        path: './_site'

  deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
    - uses: actions/checkout@v2
    - uses: kheiakiyama/install-azcopy-action@v1 # azcopy のインストール。詳細は別記事で。
      with: 
        version: 'v10'
    - name: Download jekyll output # build job でアップロードした Artifact をダウンロード。 name と同名の path にダウンロードされる
      uses: actions/download-artifact@v1
      with:
        name: jekyll
    - name: azcopy upload jekyll content # azcopy で Blob Storage にコンテンツをアップロード
      run: |
        azcopy --version | grep 'azcopy'
        azcopy --source ./jekyll --destination "$BLOB_CONTAINER_URL" --dest-key ${{ secrets.STORAGE_KEY }} --recursive --quiet --set-content-type
      env:
        BLOB_CONTAINER_URL: 'https://kheiakiyama.blob.core.windows.net/$web'
    - uses: azure/login@v1 # Azure CDN のパージのために azcli でログイン
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}
    - name: Azure CLI script # Azure CDN パージ
      uses: azure/CLI@v1
      with:
        inlineScript: |
          az cdn endpoint purge -g kheiakiyama.com --profile-name kheiakiyama-cdn -n cv-kheiakiyama --content-paths '/*'

Travis CI の頃からこのリポジトリは public なのだが、GitHub Actions の実行ログにしてもシークレットは見えないので、特に問題ではない。
(Azure Resource の名前は見せているが、まあ特に問題ないかと)

感想

Azure DevOps の fork というのには納得で、Multi staging build の Azure Pipelines とほぼ同じ使い勝手だった。
Azure Pipelines でいうところの Task は GitHub Actions ではまだ充実していないところがあるという感じ。
Azure 関係の GitHub Actions は結構数がある様子。

GitHub Marketplace · Actions to improve your workflow · GitHub

開発者が 3rd Party の Actions を作れるので、今後 GitHub Actions がどの程度充実していって Azure Pipelines と差がついていくのかを見守っていきたい。

Azure Resource Magement テンプレートを書くときにやっていること

大まかに以下の流れで行っている。

  1. 完成品を Azure Portal 上で実装
  2. Azure Portal 上でテンプレートを Export
  3. Visual Studio Code 上で編集
  4. Azure Portal 上でデプロイテスト、問題があれば一つ前に戻る

完成品を Azure Portal 上で実装

動作を確認する意味でも完成品がなければ何も進まない。
ありものをベースに書く。

Azure Portal 上でテンプレートを Export

以下のドキュメントの手順の通りにテンプレートを Export する。

docs.microsoft.com

自分で一から書くのは手間なので動いているものをそのまま落としてくるのが手っ取り早い。

Subscription Id や Resource Group Name などのパラメータがハードコードされているのがちょっと惜しい。
これについて Twitter に書いたところ PM っぽい人が反応してたので、返信したがその後返信がない。。。

Visual Studio Code 上で編集

以下のようにエディタの拡張機能もあるので、Visual Studio Code の生産性が高い。

marketplace.visualstudio.com

先に書いたパラメータの件などはここで書き換える。
テンプレートで使える関数は以下。concatresourceId あたりはほぼ必須だろう。

docs.microsoft.com

他にもリソースの種類によっては「こういうときにどうするのがいいんだろう?」という場面に出くわすことがある。
そういうときは以下の公式テンプレート集から同じシチューエーションを探して参考にする。
たとえばダウンロードしたテンプレートでは書かれている内容でもテンプレートとしては不要な記述が結構あるので、それをどこまで削るべきかといった判断に役立つ。

github.com

Azure Portal 上でデプロイテスト、問題があれば一つ前に戻る

完成したテンプレートを使ってデプロイし、思ったとおりデプロイされたリソースが動くか確認する。

テンプレートを使ったデプロイは以下のドキュメントの通り。

docs.microsoft.com

2019年に買ってよかったもの

今年はブログをあまり書けなかった。
生存報告も兼ねて今年も買ってよかったものをまとめておく。

ガジェット

加湿器は消耗品だと思っていて基本使い捨てるスタイル。
スチーム式が好きなので今回は構造がシンプルそうな山善の加湿器を購入した。
手入れは簡単といいつつもほぼ毎日使っているためか、クエン酸で定期的に掃除しないとダメな感じ。

iPhone のカバーとして優秀。
ケータイを物理的に壊して修理に出したことはないが、年1,2回くらい落としてカバーを交換していて、それが3回もカバーされるのは非常に便利。

スマホの充電ケーブルを持ち歩くため、仕事用のバッグやプライベート用のバッグなどの間でよく持ち物を入れ替えていたがよく忘れることがあり、そもそもすべてのバッグに入れておけば忘れないということに気づいたので一気に購入した。

キッチン

フルグラを愛好している身としてはベストバイ。
適量を食べるために必要。

2年くらい先送りしてきたが、ついに Kubernetes を触る機会が巡ってきたので真壁さんが共著されているこの本で基本を抑えた。
本に沿って手を動かすまではできてないが、何度も読み直す想定でいい本。
サンプルコードの GitHub - ToruMakabe/Understanding-K8s: [翔泳社 しくみがわかる Kubernetes] サンプルコード を眺めるだけでも何かしら発見がある。

正直不動産(1) (ビッグコミックス)

正直不動産(1) (ビッグコミックス)

普段触れない業界について書かれている漫画が好きで、この漫画を通じて不動産業界に詳しくなれた気がする。

東京 マニアック博物館 おもしろ珍ミュージアム案内 決定版

東京 マニアック博物館 おもしろ珍ミュージアム案内 決定版

  • 作者:
  • 出版社/メーカー: メイツ出版
  • 発売日: 2018/03/20
  • メディア: 単行本(ソフトカバー)

Wikipedia のように知識欲を満たしてくれる博物館が世の中にたくさんあることがわかる。
博物館いくつか行ったときにこの手の本が置いてあり、こういった本の存在を知ったことで購入。
検索でなかなかたどり着けない情報網羅性があり便利。
時間があるときに制覇していきたい。

最後に

Amazon の注文履歴を辿って書いてるが、思ったより Amazon で買ってない説ある。

Azure で Nomad(Consul)のクラスターを作成する

Web サーバーとスケジュールジョブなら App Service と Logic App + Azure Container Instance が最初の選択肢だと考えていたが、他の選択肢を調べてみようと検証した。

Nomad 事情

Nomad は Hashicorp のプロダクト。
Nomad by HashiCorp

日本に馴染みがあるところでは Circle CI や trivago が使っている。
Who Uses Nomad - Nomad by HashiCorp

trivago の記事で KubernetesNomad の違いについて触れている。
"(意訳)Kubernetes は自動車だとしたら Nomad はスクーターで、場合に応じて使い分けます"
Maybe You Don't Need Kubernetes | Matthias Endler

公式でも Kubernetes との違いについて触れている。
"(意訳)Kubernetes は Docker にフォーカスしてますが Nomad は一般的な利用を想定しています"
Nomad vs. Kubernetes - Nomad by HashiCorp

Nomad が Docker 特化ではないとはいえ k8s を使うべきシーンはそこまで多くないと考えていて、Nomad がそのときの代替案になるのではないかと考えている。

知るかぎり Nomad の as a Service はないため、下回りは自分で整える必要がある。

事前知識

  • Nomad 公式の Getting Started を完了している
  • Azure Virtual Machine やその周辺の知識を保持している
  • Terraform は利用している
  • Consul と Packer は触ったことがない

チュートリアル

Hashicorp が手順を用意してくれているので、それに沿って行う。

github.com

Nomad と Consul を同じクラスターにデプロイすることにし、"Deploy Nomad and Consul in the same cluster" の手順を追う。
手順の中で terraform-azurerm-nomad を見ていたと思ったらリンク先が terraform-azurerm-consul でいつの間にか違うリポジトリ、ということがあるのでそこは注意すること。

Consul と Nomad 入りの VM イメージ作成

Use the install-consul module from the Consul Azure Module and the install-nomad module from this Module in a Packer template to create an Azure Image with Consul and Nomad.

Packer 使って VM Image を作成してねということなので、リポジトリ内の以下を参考に作成する。
https://github.com/hashicorp/terraform-azurerm-nomad/tree/master/examples/nomad-consul-image

Packer 初めてだったのでよくわからずにそのまま packer build nomad-consul.json したが、できていた。
環境変数として与える Service Principal のスコープを制限しようとしたところ、packer-XXX というリソースグループを作成できる必要があり、そこだけハマった。

Consul と Nomad のサーバークラスター作成

Deploy a small number of server nodes (typically, 3) using the consul-cluster module. Execute the run-consul script and the run-nomad script on each node during boot, setting the --server flag in both scripts.

Terraform を使ってクラスターを作成する。
クラスターは Virtual Machine Scale Set で構成されている。
ドキュメントを読んで必要なパラメータを入れれば構成できる、はずなのだが Consul と Nomad が動いておらず、デプロイ後にミドルウェアのインストールを SSH で接続して行った。
ここは仮想マシンの起動スクリプトで完結できないと不便なので、実用するときはもう少し掘り下げる予定。

Consul と Nomad のクライアントクラスター作成

Deploy as many client nodes as you need using the nomad-cluster module. Execute the run-consul script and the run-nomad script on each node during boot, setting the --client flag in both scripts.

基本的にサーバークラスターと同じ要領で作業を進めるのみ。
自分の場合はサーバークラスターを作成した時点でコア数上限に引っかかり、別リージョンに作成した。
Consul と Nomaddatacenterregion の値は terraform テンプレートにリージョンとして書いてある値に準じるため接続できないエラーが出ていた。
デプロイ後に config を書き直すことで対応。

感想

Consul サーバークラスターのマネージドサービスが現在プライベートベータになっている。
Announcing HashiCorp Consul Service on Azure

Kubernetes も踏まえてこれを提供しているようだが、Nomad のマネージドサービスが欲しいなという印象。
そうはいっても現状はないので、Virtual Machine Scale Set をうまく使って仮想マシンを操作する必要がないように起動スクリプトを整備するのと、Consul と Nomad のアップデートなどの運用フローを整備できれば実用に耐えられるかなという印象。

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス