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 ―クラウドにおけるサーバ管理の原則とプラクティス

DMM英会話の予約メールから自動的にカレンダー予約(2019/9/3改訂版対応)

追記

2021/1/5 時点で利用可能なことを確認済み

背景・問題

DMM 英会話を使い始めて9ヶ月近くになる。
DMM 英会話ではレッスンを登録すると、その日時が書かれたメールが届く。
スケジュール管理の都合上、以下の記事を参考に Google カレンダーに自動登録するハックを利用していた。

blog.shotarok.com

しかし、2019/09/03 に予約メールが重複して届くようになり、翌 09/04 には新しいフォーマットのメールのみ届くようになってしまった。

以前のメールフォーマットに依存していたため、これまでのハックが使えなくなってしまった。

原因

システム改訂にともなうフォーマット変更だと思われる。

2019/09/03 までのメール

  • タイトル「【DMM英会話】レッスン予約完了のお知らせ」
  • 送信元 no-reply@eikaiwa.dmm.com

2019/09/03 から後のメール

  • タイトル「レッスン予約」
  • 送信元 noreply@eikaiwa.dmm.com

解決策

Google Apps Script を少し修正した。

DMMEnglish.gs だけ修正すれば問題ないはず。
レッスン5分前あたりにリマインドメールが届くのだが、自分の場合はメール見てないのでこれも開封したことにしている。

function DMMEnglish() {
  var criteria = "from:noreply@eikaiwa.dmm.com レッスン予約";
  eachUnreadMessage(criteria, function (message) {
    var body = message.getBody();
    var [matched, year, month, day, sh, sm] = /様、(\d+)\/(\d\d)\/(\d\d)\s(\d\d):(\d\d)/.exec(body);
    var sdate = new Date(year, month-1, day, sh, sm);
    var edate = new Date(sdate.getTime() + 30 * 60000);
    createEvent("DMM英会話", sdate, edate, "https://eikaiwa.dmm.com/book/book_list/");
  });
  // レッスン前のリマインドメールも開く
  criteria = "from:noreply@eikaiwa.dmm.com レッスンのお知らせ";
  eachUnreadMessage(criteria, function (message) {
    //開くだけ
  });
}

ほかの設定はさきのブログ記事に準じたままなので、このスクリプトだけ直せばOK。

地方出身ITエンジニアが上京して2年経った今ギャップを考える

2019年も始まり、気づけば東京に来てから丸2年が経った。
2017年1月に転職と同時に上京したのだが、上京前に考えてたことと今それについてどう思うかをまとめる。


ITイベントいっぱい出(られ)る説

地方(富士市)にいたときは大きいイベントだけ参加していた。
当時参加したイベントは デブサミCROSSHTML5 Conference など。
日帰りで技術の関連性があるものはギョーム扱いで参加もしたこともあった。

上京直後は TECH PLAY から流れ込んでくる Connpass などの勉強会情報で関連性がある技術のものを片っ端から登録し、参加していた。
誰かに紹介されたものも基本されるがままに参加してた。

半年から1年くらい経った頃、IT勉強会に出ても技術は身につかないことがわかってきたので、最近はかなり選別して参加している。
コミュニティ活動を通じて知り合い増やしたりネットワーキングするようなことは全く得意ではないので、そういう人だとバンバン出ているようだ。これができる人はすごい。
技術動向を掴んだり、モチベーションを高めたり、もくもく作業したりするものを中心に参加していきたい。


優秀なITエンジニアいっぱいいる説

地方では 2:6:2 の法則がだいたい当てはまっていた。

この法則は現在も当てはまっていると思う。
ただ圧倒的に人が多いことと競争が多いためか、相対的にスキルが高いと感じる。
またクライアントワークするようになった関係か、お付き合いする会社の中にITエンジニアに限らずとびきり優秀な人がいたりして、やはり優秀な人はいるものだと思う。

あと一つ前のIT勉強会の話にも関連するが、東京のITエンジニアはみんな週末も勉強しているのかと思っていたが、そんなことはなく、勉強会に出てくるエンジニアは 2:6:2 の最初の2くらいだと思う。
勉強会ばかり出ているとすごい人と出くわすことが多いので、みんなそうかのように感じてしまうこともあるが、意外とそんなことはないし、勉強会を主催してみて主催のハードルが思っていたより低いこともわかったので、そこまで引け目を感じる必要はない。


求人多い説

多いと思っていたが多かった。
ただそれなりの高給が期待できる求人は、求人サイトよりも紹介のほうが期待できる。
採用は金銭的にも時間的にもコストがかかり、競争が激化しているのは日本どこも同じようだ。

待遇を気にしなければ求人がないということはありえないので、地方の程度によってはそもそもITエンジニアの求人すら存在しないので、そこと比べれば全然違う。
公共交通機関が整っていない状態で市内の求人が3件くらいしかないのは話にならない。
供給が追いついていないとも言えるので自分で開業すればいいのかも。需要はわからん。


転職頻度高い説

僕自身新卒採用の会社に12年おり、新卒採用中心だったために平均在籍年数がたぶん6-7年くらいはあったはず。
東京は2-3年でポンポン転職する人が多いと思っていた。

実際のところは短い頻度で転職する人とそこそこ長い年数で転職する人に大別できる気がしてる。
このバランスが地方では 3:7 東京では 7:3 くらいになっているのかな。
そういう意味ではそこそこ頻度が高い。


最後に

ということで本年もよろしくお願いします。

アフィリエイト眺めてたら見つけた謎のTシャツ