GitHub Actionsの書き方(基本)

GitHub Actionsとは？

ビルド、テスト、デプロイなどを自動化するCI/CDプラットフォームのこと。GitHub内のサービスのため、GitHub内で完結することができる。

GiHub Actionsの仕組み

• 設置場所：.github/workflows
• ファイル形式：yml
• 記載内容：ワークフロー
• トリガー条件：push, pull_requestなど

WorkflowはJob単位で分けられて、Runner(仮想マシンのインスタンス)上で実行される。

JobはさらにStep単位に分けられていて、この中でコマンドが実行される。

GiHub Actionsの書き方

job(処理の最上位単位)

jobは複数定義可能で並列実行される

jobs:
  my_job1:
    name: My job1
  my_job2
    name: My job2

on(処理実行条件を指定)

on: [push] # push時にjobsを実行

イベント	説明
push	リモートリポジトリへpush時
pull_request	プルリクエスト作成時
deployment	デプロイ時
release	リリース時
issues	GitHub Issues関連の処理発生時
schedule	cronによる定期実行

上記以外のイベントはこちらを参照

run-on(ジョブを実行するOS(ランナー)を指定)

runs-on: ubuntu-latest # ubuntuの最新版を指定

uses(第三者もしくはGitHubが作成したActionsを利用)

- name: Checkout
    uses: actions/checkout@v4

usesに指定できるActionsは以下で検索して調べる
GitHub Marketplace · Actions to improve your workflow · GitHub

@以下に指定するバージョンの扱いについては以下が詳しかった
GitHub Actions の uses でメジャーバージョンを参照するのはリスク マイナーバージョン指定が良さそう。信頼性が懸念される場合は、SHA指定が一番安全

Actionsの信頼性は、GitHub Marketplace の「Verified creator」バッジが参考になる

step, run(job内のstep要素とコマンド実行するrun)

リモートリポジトリにpushするとファイル構成の確認、actions/checkout@v4を実行する

name: command
on: [push]
jobs:
  command:
    name: Use Linux commands
    runs-on: ubuntu-20.04
    steps:
      - name: Inspect files before checkout
        run: ls -la # Linuxコマンドを実行可能
      - name: Checkout
        uses: actions/checkout@v4 # ワークフローを実行するリポジトリをチェックアウト

env(ワークフロー内に環境変数を設定)

変数名: 設定値という書き方で設定可能

env:
  SECRET_KEY: test
  ALLOWED_HOSTS: 127.0.0.1

参考URL

• 【初心者向け】【入門】GitHub Actionsの書き方についてデバッグ設定、runs-onやcheckoutなどの仕組みや構造も含めて徹底解説 #Linux - Qiita
• 【GitHub】GitHub Actionsの使い方、構文について徹底解説！！

Apache Kafkaとは？

Apache Kafkaとは？

複数台のサーバーで大量データを処理する分散メッセージングシステムのこと。

メッセージングシステム

リアルタイムに生成される大量データを中継するシステムのこと。

データ生成場所とデータ利用場所が複数ある場合、そのデータを直接やり取りすると複雑になっていくため、一時的にデータを貯めて置く場所としてこのシステムは使われる。

利用メリット

• データ生成場所・データ利用場所ともに接続先を一つにできるため、シンプルな構成にできる。
• 新しい データ生成場所・データ利用場所が作られてもメッセージングシステムに繋げば良いだけなので実装コストを下げられる。

Apache Kafkaの構成

構成要素	説明
Broker	データを送受信するサービスで中継役
Message	Kafkaが受診し送信するデータの単位
Producer	データの送信元。BrokerにMessageを送信する
Consumer	データの送信先。BrokerからMessageを取得する
Topic	Mesageを種類ごとに管理するためのストレージ。Broker上で管理

Apache Kafkaの特徴

分散システム

データ量が増えてくると障害時にデータ欠損やデータ送信失敗となったりする。これらに対応するために分散システムを実現している。

構成要素	説明
Partition	Topicを細分化する単位
Replica(Leader)	Partitionの複製。Producerからメッセージを受信、Consumerに送信する。各Partitionに必ず一つ存在
Replica(Follower)	Partitionの複製。Leader Replicaからメッセージを取得して複製。障害時に送信する

• 各Replicaは異なるBrokerに配置されることで分散処理を実現
• 一つのMessageの複製が複数サーバーで管理される

分散システムのメリット

• スケールアウト可能：Brokerを増やしPrtitionを再配置することで役割の分散と性能向上を実現できる
• データ欠損の低減：別Brockerにデータの複製があるため、障害が発生してもデータがなくならない。Leaderで障害が発生してもFollowerがLeaderの役割を引き継ぐためデータ送受信を継続できる

データの永続化

KafkaではBrokerがProducerからMessageを受け取ると、ディスク上へ保存する。これによりConsumerは任意のタイミングでMessageを取り出し可能になります。

データ永続化によるメリット

• バッチ化の実現
  • Brocker上に溜まった複数MessageをConsumerが一括受信する。データを順次処理するストリーム処理なども実装かのう
• Consumber障害発生時のBrokerへの影響が少ない
  • Consumerが障害となってもBroker側でデータ送信停止などがいらない。Consumerからのリクエストに応じてBrockerが送信する仕組みになっているので

参考URL

• Apache Kafka 超入門 #初心者 - Qiita

Intellij 便利プラグイン

便利そうと思って導入したプラグインの概要について以下に記載する。
詳しい内容は、参考URLを参照のこと。

便利プラグイン

コード共有

• GitLink：エディタ上のコードを右クリックで、コード共有リンクコピーのメニューを出せる

コード理解

• Find Pull Request：エディタ上のコードを右クリックで、カーソルのコードを最後に編集したPRへジャンプするリンクを表示
• GitToolBox：選択行右側にCommitのAuthor名やCommitメッセージが表示

コードリーディング支援

• Rainbow Brackets：対応括弧をレインボーにハイライト
• JsonParser：JSONのvalidateやformatを行ってくれるものです。 手入力したJSONが正しいフォーマットになっているか確認したい、一行にまとめられていて人間が理解するのが困難なJSONを読みたいに使える

操作効率化

• Key Promoter X：マウスのクリックで行った操作に対して、ショートカットを使わなかったことの指摘を通知

参考URL

• engineer.retty.me
• 開発が捗るIntellij IDEAの便利機能&おすすめプラグイン - asoview! Tech Blog

Confluence PlantUML シーケンス図 ノートの表示位置調整

メッセージに付けるノートが思うように出力できなかったので、記載しておく

• note 【表示位置】 of 【起点の要素】
• 【表示位置】 ：right left over
• 【起点の要素】：participantで定義した要素

参考ソースと画面イメージ

@startuml
participant Alice
participant Bob
note left of Alice #aqua
This is displayed
left of Alice.
end note

note right of Alice: This is displayed right of Alice.

note over Alice: This is displayed over Alice.

note over Alice, Bob #FFAAAA: This is displayed\n over Bob and Alice.

note over Bob, Alice
This is yet another
example of
a long note.
end note
@enduml

参考

plantuml.com

AWSやKubernetes周りのツール 概要

AWS App Runner

• ECRにコンテナイメージをpushまたは、GitHubにコードpushすると、自動デプロイしてくれる
• コンテナがデプロイされるとApp RunnerがマネージドのLBを設定してくれる
• コンテナ管理とかVPC周り、ALB,NLBとかscalingなどを隠蔽して提供してくれる

Kubernetes Ingressコントローラー

• Kubernetes環境用ロードバランサー
• Kubernetesアプリケーションのトラフィックルーティングを抽象化して複雑さを排除し、Kubernetesサービスと外部サービスを橋渡をする

参考

• Nginx Ingress Controller完全に理解した

サービスメッシュとIstio

マイクロサービスの課題

• 近年、マイクロサービスが大流行しているがネットワークに関係する課題がある
  • トラッフィク管理、可観測性、セキュリティの３つ

ネットワークに由来する課題解決のための機能

マイクロサービスシステムの運用には、分散システムのネットワークに由来する課題が存在しており、その解決のための様々な機能の実装が必要となる。

• トラフィック管理
  • サービスディスカバリ
    • サービスを利用する際、ドメイン名などのサービス識別子からIPアドレスなどの実サーバ接続情報を明示的/暗示的に得ること
  • 負荷分散
  • スロットリング
    • 一定の時間内に、事業者が特定の操作に対して送信できるリクエストの数を制限するプロセス
  • サーキットブレイカー
• 可観測性
  • モニタリング
  • ロギング
  • 分散トレーシング
• セキュリティ
  • サービス間の認可
  • 相互TLS

各種ライブラリを用いて、これらを実装して問題解決することも可能であるが、多くのマイクロサービスを抱える場合、統一的な問題解決をするのが難しくなってくる。

サービスメッシュが解決する課題

すべてのマイクロサービス間の通信に対して、一貫した仕組み(サーキットブレーカー、ログ、メトリクス、認証認可など)を提供するのがサービスメッシュ。

Istioの概要

Data Plane

• マイクロサービス間のすべてのネットワーク通信を仲介・制御する
• すべてのPodにEnvoyをサイドカープロキシとして配備する
• アプリケーションは、IstioやEnvoy Proxyのための設定が不要となり、ビジネスロジックの実装に集中できるようになる
• マイクロサービス間の通信の観測結果を収集し、レポートする

Control Plane

• Data Planeを管理する
• istio-initによって、Kubernetesクラスター内のすべてにEnvoy Proxyを注入する
• RouteRuleなどの設定を常に最新に保つように、Reconciliation Loopを実行する
• 可観測性の向上のためにログ集約するなどを行う

Istiod

• サービス検出・構成・証明書管理を行う
• 構成要素
  • Mixer : Envoy を通して各サービスのデータを収集し、その情報を元にアクセスコントロールを行う
  • Pilot : サービスディスカバリやトラフィック管理などを行う
    • A/Bテスト・カナリーリリースの実現や、タイムアウト・リトライ・サーキットブレーカーなどの手法を用いて Fault Isolation（障害の分離）の問題を解決することができる
  • Citadal : サービス間認証とエンドユーザ認証を実現する
    • この認証を利用することで、ポリシーベースでサービスメッシュを管理することができる。

サービスメッシュの本質

• サービスメッシュの解決課題は、トラフィック管理、可観測性、セキュリティではない
• インフラのコード化を実現したのがKubernetesこれをネットワークの世界に適用したのがサービスメッシュツールであるIstio

サービスメッシュの仕組み

• サービスメッシュはアプリのサイドカーなので、拡張が可能
• IstioのProxyとしてのEnvoyは、Envoyフィルタを利用して拡張を行う
• Envoyフィルタは、Envoyコア機能に影響を与えずにカスタム機能を定義する
• envoy.yamlによって追加機能をコード化することでIaCを実現可能

参考

• サービスメッシュの本質は、トラフィック管理や可観測性ではない
• サービスメッシュと Istio の基本を理解する - Linkode.TechBlog

UUID, ULIDとは？

UUIDとは？

開発時にデータに一意なIDを割り振る際によく用いられる。

UUIDには複数のバージョンがあり、UUID v4がよく用いられている。

特徴

• ビット幅は 128ビット(16バイト) で、文字列表現では16進法で以下のような形で表現する。
• （32バイト+バウンダリ4バイト=36バイト。 "-" がバウンダリ文字列）

550e8400-e29b-41d4-a716-446655440000

UUID v4

• UUID v4は、ランダムな値に基づいて生成される128ビットの識別子
• 生成ごとに完全にランダムな値が生成される
• 衝突可能性も0ではないが、現実的には衝突ので安全に利用できる

UUID v7

• UUID v7は、UUID v4と同様に128ビットのランダムな識別子
• 現在の時刻を表すタイムスタンプに基づいて生成される
• タイムスタンプは、ナノ秒単位の精度まで含まれる
• このため、生成時刻の順序が保証され、生成時刻を基準にソートが可能

ULID

• ULIDとは、UUIDと同様にランダムな識別子
• UUID v4とは違い、先頭48ビットにタイムスタンプを置くことにより、ソート可能
• 1ミリ秒単位でソート順が保証されており、同一の生成器であれば2⁸⁰までソート順が保証される。

それぞれの識別子フォーマット

UUID（Ver.4）
2ec40df6-7587-42ee-bf83-ef97a3e46556

UUID（Ver.7）
018422b2-4843-7a62-935b-b4e65649de3e

ULID
01GWKR0SQ0KD0QZ3SHEEAM8YDJ

参考URL

• UUIDとULIDの違いと種類を解説【ULID＝ソート可能なUUID？】｜東京のWEB制作会社・ホームページ制作会社｜株式会社GIG
• MySQL に UUID のデータを 16 byte で保存する #Java - Qiita