GitHub Actions 逆引きリファレンス

1.この記事の立ち位置 自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ 2-1.Step と Job と Workflow の違いの一行まとめ Step < Job < Workflow 2-2.Step と Job と Workflow の違いの三行まとめ Step はGitHub Actions Workflow の最小単位であり、run や uses で指定するもの Job はコンテナや VM のことを指し、runs-on で指定するものであり、ひとつないしは複数の Step を抱えている Workflow はひとつ以上の Job を束ねている これらについて端的にまとめた図が公式ドキュメントで掲載されているのでそちらもぜひ。 Understanding GitHub Actions - GitHub Docs 2-3.Step と Job と Workflow それぞれの分け方・分割の基準 Step を分けるときは、run 、 uses 、 name が異なるとき 以下のように書けば、ひとつの Step に複数のコマンドを始めとする処理を書くことができる - name: Install Dependencies run: | npm ci npm run build - name: Run test run: npm run test Job を分けるときは runs-on が異なるときや、needs で Job 単位で実行制御をしたいとき cf....

May 24, 2022 · 7 min · gkzz

Helm Charts の宣言的デプロイツールの Helmwave に入門する

1.この記事を書こうと思った背景 Helmwave なるものを Twitter で見かけた。 Helmwave is a release manager for #Kubernetes, akin to Helmfile and Helmsman: https://t.co/hxa5sYmHgp — Kubernetes Tools & Utils (@kubectrl) May 4, 2022 Helmwave の README.md にはこのように書かれている。 Helmwave is helm3-native tool for deploy your Helm Charts. HelmWave is like docker-compose for helm. Helmwaveは、Helmチャートを展開するためのhelm3ネイティブツールです。 HelmWaveはdocker-composeのようなものですhelm用に作成します。 出所:helmwave/helmwave: 🌊 Helmwave is true release manager (邦訳はGoogle翻訳より) よさそうなので、公式ドキュメントの Getting Started などを参考に Helmwave に入門する。 2.前提 2-1.ところで、Helm とは? ぼくは、Helm 及び Helm Charts の理解も浅いのでこの場で深めておく。まず、Helm については公式ドキュメント にこのように書かれている。...

May 13, 2022 · 8 min · gkzz

作成したKubernetesのNamespaceを削除しようとしてもTerminatingのまま削除できないのでkubectl replaceコマンドでImperative(命令)的に削除する

1.この記事を書こうと思った背景 Amazon EKS 上で作成した Namespace を kubetcl delete namespace <namespace> と削除しようとしても削除できないことがあった。(ここで削除したい Namespace は argocd) $ kubectl get ns argocd NAME STATUS AGE argocd Terminating 50m $ kubectl get namespace argocd -o json { "apiVersion": "v1", "kind": "Namespace", "metadata": { "creationTimestamp": "2022-05-06T15:36:43Z", "deletionTimestamp": "2022-05-06T16:15:02Z", "labels": { "kubernetes.io/metadata.name": "argocd" }, "name": "argocd", "resourceVersion": "16545", "uid": "7e29177f-2c2c-4583-b027-49946160bf2b" }, "spec": { "finalizers": [ "kubernetes" ] }, "status": { "conditions": [ { "lastTransitionTime": "2022-05-06T16:15:09Z", "message": "All resources successfully discovered", "reason": "ResourcesDiscovered", "status": "False", "type": "NamespaceDeletionDiscoveryFailure" }, { "lastTransitionTime": "2022-05-06T16:15:09Z", "message": "All legacy kube types successfully parsed", "reason": "ParsedGroupVersions", "status": "False", "type": "NamespaceDeletionGroupVersionParsingFailure" }, { "lastTransitionTime": "2022-05-06T16:15:09Z", "message": "All content successfully deleted, may be waiting on finalization", "reason": "ContentDeleted", "status": "False", "type": "NamespaceDeletionContentFailure" }, { "lastTransitionTime": "2022-05-06T16:15:09Z", "message": "Some resources are remaining: applications....

May 7, 2022 · 2 min · gkzz

"A Conversation with Werner Vogels - ACM Queue"を読んだ

1.この記事を書こうと思った背景 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 (通称、ちいとぽ本)を読み進めていくうちに、以下の疑問を抱くようになった。 Amazon社のピザ2枚ルール、チーム間のコミュニケーションは、インターフェイスを通して行うことというルールは実際にどんなかんじにされているのか? 気になる。 Teams must communicate with each other through these interfaces. 出所:AmazonのAPI設計方針 (The Bezos Mandate) - Qiita 明確な答えを導き出したわけではないけれども、考えを深めることができたターニングポイントとなったのが、タイトルで触れているインタビュー記事、A Conversation with Werner Vogels - ACM Queue を読んだことだった。また、先にお伝えしておくと新たな疑問も抱くようになったので、インタビュー記事を読んで学んだことと新たな疑問について書き留めておきたい。 インタビュー記事を知ったきっかけ 左記のインタビュー記事を知ったきっかけは、Team Topologies(by Manuel Pais)のキーポイント を読んだことである。この記事は書評記事ではないが、同書の趣旨を理解する上でも大きな助けとなった。“A Conversation with Werner Vogels"をご紹介いただき、ありがとうございました! 2.“A Conversation with Werner Vogels - ACM Queue"を読んで学んだこと 各サービスの構成メンバーは 利用ユーザーの目的やニーズに応えることにフォーカス するべきだということ ↓の例だと、デベロッパーの関心事はアプリケーションを開発することであり、アプリケーションを開発するために内部的に生成されているURLがどうやって構成されるのか?には関心がないということ。責任共有モデルが各サービス間で徹底されているということ。 Do we see that customers who develop applications using AWS care about REST or SOAP? Absolutely not! A small group of REST evangelists continue to use the Amazon Web Services numbers to drive that distinction, but we find that developers really just want to build their applications using the easiest toolkit they can find....

April 29, 2022 · 2 min · gkzz

Hugo の Papermod テーマを使っているブログに favicon の設定をする

1.この記事を書こうと思った背景 favicon の設定方法はドキュメントにも記載があるけどそれだけでは足りず、手間取ってしまったのでここに備忘録として書き留めておく。 https://adityatelange.github.io/hugo-PaperMod/posts/papermod/papermod-faq/#adding-custom-favicons 2.やりかた config.yml に以下のとおり追加 params: assets: favicon: "<link / absolute url>" # e.g. "/favicon.ico" favicon16x16: "<link / absolute url>" # e.g. "/img/favicon-16x16.png" favicon32x32: "<link / absolute url>" # e.g. "/img/favicon-32x32.png" apple_touch_icon: "<link / absolute url>" # e.g. "/img/apple-touch-icon.png" ※ favicon のパスはプロジェクトのルートディレクトリに配置した ./static/ ディレクトリ内をルートとしたときの相対パスで指定 $ tree ./static/ ./static/ ├── favicon.ico └── img ├── apple-touch-icon.png ├── favicon-16x16.png └── favicon-32x32.png ./themes/PaperMod/layouts/partials/head.html をコピーし、./layouts/partials/head.html を追加 $ cp ./themes/PaperMod/layouts/partials/head.html ./layouts/partials/ $ find ./ -type f -regex "....

April 29, 2022 · 1 min · gkzz