mito’s blog

IT技術メインの雑記。思い立ったが吉日。

Cloud Native Days Tokyo 2023 参加レポート

技術カンファレンス Advent Calendar 2023 シリーズ2の14日目の記事です。

はじめに

Cloud Native Days Tokyo 2023(以下、CNDT2023)の初日に現地参加してきました。
以下に、いくつかのセッションと現地参加の感想を記載しています。

event.cloudnativedays.jp


現地参加の感想

現地参加して本当に良かったです。CODT2023に続き、久しぶりの方もオフラインでは初の方とも会えたので大満足です!
よるイベでは、初めに話した一人がつい先日弊社の研修を受けた方だったり、10数年前に同じ製品を取り扱った方、出張研修でお会いした方もいて、個人的に盛り上がりました。

スポンサーブースでは、もともと全ブースに話しかけようと思っていましたが、スタンプラリーがあるおかげで話しやすかったです。 「スタンプください、あと何を紹介してるのですか?」って。話しかけるの楽。
業務で関わり合いがあって顔見知りの方から、あまり興味のなかったジャンルの知見を得たり、これはど真ん中な競合製品だなぁって思いながら話を聞いたりなど楽しかったです。 また、企業ロゴのTシャツを集めている(よく着ている)ので、Tシャツ数枚のほかパーカー、靴下まで貰えていうことなし! 自社オフィスで赤い帽子のポロシャツを着て過ごすこともあるので!

次回もぜひ現地参加しようと思います。弊社スポンサーで出展はしなかったけど、こんなに盛況なら出展しても良さそう。


セッションの感想

現地の人と交流してる時間が長く、後追いで見る予定です。 徐々に更新していきます!


「noteのKubernetes移行、ゼンブ見せます」

event.cloudnativedays.jp

  • 登壇者
  • ソフトウェア式年遷宮という考え方が興味深かった
    • クラウド移行をする際に参考になりそう。特に、後々困りそうな技術の継承は深掘りしておきたい
  • Kubernetesになれてないエンジニアにも操作できるよう、運用系ツールを開発
  • 上記だけでなく、ゼンブ見せますという言葉通り、ゼンブ見れます!


「10年モノのサービスのインフラを漸進的に改善する、頑張りすぎないクラウドネイティブ」

event.cloudnativedays.jp

  • 登壇者
  • 課題に対する頑張りすぎない改善策(どれだけコストをかけるか?)
    • 課題
      • バッチ周辺システムが10年物で、Ubuntu12.04のEC2インスタンス10台
        • 対応への切っ掛けは、AWSAPIがTLS1.1以下の接続をサポート終了
    • 対応
      • TLS1.2以上の通信に対応するほか、運用上の課題を洗い出し、各課題への優先度をつけ対応策を検討
      • コストと期待する成果を観点に入れることで、対応方針を決めやすくなった
      • 課題解決の目的意識を持つことで、クラウドネイティブを頑張らなくていい判断ができた
        • コンテナ化やサーバレスのようなクラウドネイティブ技術を導入しなくても解決できる


人工衛星の運用を支える、クラウドネイティブ民主化への取り組み」

event.cloudnativedays.jp

  • 登壇者
    • Synspective Inc. Masaya Araiさん @msy78
  • 宇宙開発・人口衛星分野でクラウドネイティブ技術が大いに活用されていることを知ってほしい
    • 地上システムやソリューション/データプラットフォームはGoogleCloud(GKE/OSS/BigQueryなど)で動いている
    • 観測衛星事業に関連する法律やコンプライアンス規制に基づくビジネス制約を加味しながら、クラウドネイティブ技術を活用している
  • クラウドネイティブ技術で技術の民主化とオーナーシップが高められることを知ってほしい
    • 民主化を進めるうえで大切なこと「スモールスタート」「既存の開発体験を極力壊さない」「利用を強制しない」「フィードバックを大切にする」

Terraform Provider for Ansible「resource "ansible_playbook"」を試してみた

terraform Advent Calendar 2023 の11日目の記事です。

はじめに

気になっていた Terraform Provider for Ansible をこの機に試してみました。
今回の対象は resource "ansible_playbook" です。


試した感触

TerraformとAnsibleを組み合わせるなら、今のところリソースansible_hostを使って、別途Playbookを実行したほうが良さそうです。

本投稿に成功したログを残していますが、投稿の検証のためにapply/destoryを繰り返していたところ、 削除したはずのホストがインベントリに表示していたり、ansibleプラグインが読み込めなかったこともありました。
時間を見つけて調査してみようかと。

mitomito.hatenablog.jp



環境

Ubuntu 22.04.3に構築しています。

  • Terraform : 1.6.5
  • Ansible core : 2.15.6
  • Python : 3.10.12


TerraformでEC2インスタンスを構築する

tfファイル、ansible.cfg、Playbookを作成し、実行します。


Terraformの定義ファイルの作成

resource "ansible_playbook" がPlaybook実行のリソースです。

terraform {
  required_providers {
    ansible = {
      version = "~> 1.1.0"
      source  = "ansible/ansible"
    }
  }
}

provider "aws" {
    region = "ap-northeast-1"
}

### playbookのメインとなるリソース
resource "ansible_playbook" "playbook" {
    playbook                            = "playbook.yml"
    name                                = aws_instance.server.public_dns
    replayable                          = true   ### terraform applyの度に、Playbookを実行

    extra_vars = {
        ansible_user                    = "ec2-user"
        ansible_ssh_private_key_file    = "~/.ssh/xxxx.pem"
    }
}

## 確認できる4つのoutputを表示
output "args" {
  value = ansible_playbook.playbook.args
}

output "temp_inventory_file" {
  value = ansible_playbook.playbook.temp_inventory_file
}

output "playbook_stderr" {
  value = ansible_playbook.playbook.ansible_playbook_stderr
}

output "playbook_stdout" {
  value = ansible_playbook.playbook.ansible_playbook_stdout
}

resource "aws_instance" "server" {
    ami                         = "ami-012261b9035f8f938"
    instance_type               = "t2.micro"
    key_name                    = "xxxx"
    associate_public_ip_address = "true"
    vpc_security_group_ids      = [aws_security_group.blog_sg.id]

    tags = {
        Name                    = "mito-ec2"
    }
}

resource "aws_security_group" "blog_sg" {
    name        = "blog_sg2"
    description = "blog_sg"

    dynamic "ingress" {
        for_each = [22]    # 

        content {
            from_port   = ingress.value
            to_port     = ingress.value
            protocol    = "tcp"
            cidr_blocks = ["0.0.0.0/0"]
        }
    }

    egress {
        from_port   = 0
        to_port     = 0
        protocol    = "-1"
        cidr_blocks = ["0.0.0.0/0"]
    }
}


ansible.cfgの作成

ホストキーのチェックを無効にします。 ドキュメントに記載はなかったのですが、今回コンフィグファイルは読み込めたようです。

[defaults]
host_key_checking = false


AnsibleのPlaybookの作成

gitをインストールするのみのPlaybookです。

---
- hosts: all
  gather_facts: no
  become: yes

  tasks:
    - name: install git
      ansible.builtin.yum:
        name: git
        state: present


terraform applyの実行結果

terraform applyを実行します。

$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # ansible_playbook.playbook will be created
  + resource "ansible_playbook" "playbook" {
      + ansible_playbook_binary = "ansible-playbook"
      + ansible_playbook_stderr = (known after apply)
      + ansible_playbook_stdout = (known after apply)
      + args                    = (known after apply)
      + check_mode              = false
      + diff_mode               = false
      + extra_vars              = {
          + "ansible_ssh_private_key_file" = "~/.ssh/xxxx.pem"
          + "ansible_user"                 = "ec2-user"
        }
      + force_handlers          = false
      + id                      = (known after apply)
      + ignore_playbook_failure = false
      + name                    = (known after apply)
      + playbook                = "playbook.yml"
      + replayable              = true
      + temp_inventory_file     = (known after apply)
      + verbosity               = 0
    }

  # aws_instance.server will be created
()

Plan: 3 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + args                = (known after apply)
  + playbook_stderr     = (known after apply)
  + playbook_stdout     = (known after apply)
  + temp_inventory_file = (known after apply)

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_security_group.blog_sg: Creating...
aws_security_group.blog_sg: Creation complete after 3s [id=sg-07168004190e490bb]
aws_instance.server: Creating...
aws_instance.server: Still creating... [10s elapsed]
aws_instance.server: Still creating... [20s elapsed]
aws_instance.server: Still creating... [30s elapsed]
aws_instance.server: Still creating... [40s elapsed]
aws_instance.server: Creation complete after 41s [id=i-0cfa9440f6cb49b9c]
ansible_playbook.playbook: Creating...
ansible_playbook.playbook: Still creating... [10s elapsed]
ansible_playbook.playbook: Still creating... [20s elapsed]
ansible_playbook.playbook: Creation complete after 23s [id=2023-12-10 18:21:34.340075309 +0000 UTC m=+44.513961043]

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Outputs:

args = tolist([
  "-e",
  "hostname=ec2-13-115-221-150.ap-northeast-1.compute.amazonaws.com",
  "-e",
  "ansible_ssh_private_key_file=~/.ssh/xxxx.pem",
  "-e",
  "ansible_user=ec2-user",
  "playbook.yml",
])
playbook_stderr = ""
playbook_stdout = <<EOT

PLAY [all] *********************************************************************

TASK [install git] *************************************************************
changed: [ec2-13-115-221-150.ap-northeast-1.compute.amazonaws.com]

PLAY RECAP *********************************************************************
ec2-13-115-221-150.ap-northeast-1.compute.amazonaws.com : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   


EOT
temp_inventory_file = ""
$ 


インスタンスのステータスチェックをしているのか、たまたま成功したのか。。。

[Ansible X Terraform] Terraform Provider for Ansible 「resource "ansible_host"」を触ってみた

この記事は、Ansible Advent Calendar 2023 の3日目のエントリです。

はじめに

気になっていた Terraform Provider for Ansible をこの機に触ってみました。


Terraform Provider for Ansible のまとめ

  • Terrafromの定義ファイルにresource "ansible_host"を追加する
    • 上記の結果がtfstateに記載される
  • Ansibleのインベントリファイルにcloud.terraformプラグインを指定する
    • インベントリファイルがtfstateの該当箇所を読み込む



環境

Ubuntu 22.04.3に構築しています。

  • Ansible環境
    • Ansible core : 2.15.6
    • Python : 3.10.12
    • cloud.terraform : 2.0.0
  • Terraform環境
    • Terraform : 1.6.5


環境の準備

Ansibleコレクションにて、cloud.terraform をインストールします。

$ ansible-galaxy collection install cloud.terraform
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://galaxy.ansible.com/api/v3/plugin/ansible/content/published/collections/artifacts/cloud-terraform-2.0.0.tar.gz to /home/ubuntu/.ansible/tmp/ansible-local-12661qsgjsrrt/tmpzhqh3nnq/cloud-terraform-2.0.0-a_5loo9d
Installing 'cloud.terraform:2.0.0' to '/home/ubuntu/.ansible/collections/ansible_collections/cloud/terraform'
cloud.terraform:2.0.0 was installed successfully
$ 
$ 
$ ansible-galaxy collection list

# /home/ubuntu/.ansible/collections/ansible_collections
Collection                    Version
----------------------------- -------
cloud.terraform               2.0.0  

()
$ 


次に、terraformのansibleプラグインをインストールします。 ただしterrafrom initでインストールされるため、準備では割愛します。


TerraformでEC2インスタンスを構築する

3台のEC2インスタンスを構築します。


定義ファイルの作成

鍵はあらかじめ作成してあるものを流用、セキュリティグループはSSHのみ開けています。

terraform {
  required_providers {
    ansible = {
      version = "~> 1.1.0"
      source  = "ansible/ansible"
    }
  }
}

### ansible host details   今回のメイン。後述のtfstateに記載される。
resource "ansible_host" "inventory" {
    for_each                            = var.instance
    
    name                                = aws_instance.server[each.value.name].public_dns
    groups                              = ["test_group"]
    
    variables = {
        ansible_user                    = "ec2-user",
        ansible_ssh_private_key_file    = "~/.ssh/xxx.pem", # Terraformkey指定と違い、ファイル名なので拡張子も必要。
    }
}

provider "aws" {
    region = "ap-northeast-1"
}

variable instance {
    type = map
    default = {
        mito        = { name = "mito" },
        mito-ec2    = { name = "mito-ec2" },
        mito-ec22   = { name = "mito-ec22" },
    }
}

resource "aws_instance" "server" {
    for_each                    = var.instance

    ami                         = "ami-012261b9035f8f938"
    instance_type               = "t2.micro"
    key_name                    = "xxx"
    associate_public_ip_address = "true"
    
    vpc_security_group_ids      = [aws_security_group.blog_sg.id]
    tags = {
        Name                    = each.value.name
    }
}

resource "aws_security_group" "blog_sg" {
    name        = "blog_sg"
    description = "blog_sg"

    dynamic "ingress" {
        for_each = [22]

        content {
            from_port   = ingress.value
            to_port     = ingress.value
            protocol    = "tcp"
            cidr_blocks = ["0.0.0.0/0"]
        }
    }

    egress {
        from_port   = 0
        to_port     = 0
        protocol    = "-1"
        cidr_blocks = ["0.0.0.0/0"]
    }
}


terraform applyの実行結果

EC2インスタンス作成のほか、tfstateには以下のように resource "ansible_host" の結果が記載されます。

  "resources": [
    {
      "mode": "managed",
      "type": "ansible_host",
      "name": "inventory",
      "provider": "provider[\"registry.terraform.io/ansible/ansible\"]",
      "instances": [
        {
          "index_key": "mito",
          "schema_version": 0,
          "attributes": {
            "groups": [
              "test_group"
            ],
            "id": "ec2-13-114-117-20.ap-northeast-1.compute.amazonaws.com",
            "name": "ec2-13-114-117-20.ap-northeast-1.compute.amazonaws.com",
            "variables": {
              "ansible_ssh_private_key_file": "~/.ssh/xxx.pem",
              "ansible_user": "ec2-user"
            }
          },


Ansibleのansible-inventoryコマンドを実行する

まずは、resource "ansible_host" の結果がどう反映されるか確認するため、ansible-inventoryコマンドを実行します。


インベントリファイルの作成

cloud.terraformプラグインを指定します。

---
plugin: cloud.terraform.terraform_provider


ansible-inventoryコマンドの実行結果

無事に、ホスト情報が出力されました。

$ ansible-inventory -i inventory.yml --graph --vars
@all:
  |--@ungrouped:
  |--@test_group:
  |  |--ec2-13-114-117-20.ap-northeast-1.compute.amazonaws.com
  |  |  |--{ansible_ssh_private_key_file = ~/.ssh/xxx.pem}
  |  |  |--{ansible_user = ec2-user}
  |  |--ec2-35-78-213-104.ap-northeast-1.compute.amazonaws.com
  |  |  |--{ansible_ssh_private_key_file = ~/.ssh/xxx.pem}
  |  |  |--{ansible_user = ec2-user}
  |  |--ec2-13-231-192-241.ap-northeast-1.compute.amazonaws.com
  |  |  |--{ansible_ssh_private_key_file = ~/.ssh/xxx.pem}
  |  |  |--{ansible_user = ec2-user}
$ 


Ansibleのplaybookを実行する

インベントリファイルを指定して、簡単なPlaybookを実行し、動作を確認してみます。


playbookの作成

gitのみインストールします。

---
- hosts: all
  gather_facts: no
  become: yes

  tasks:
    - name: install git
      ansible.builtin.yum:
        name: git
        state: present


ansible.cfgの作成

Fingerprintのチェックを無効にしておきます。

[defaults]
host_key_checking = False


playbookの実行結果

Terraform Provider for Ansibleを指定したインベントリファイルで、正常にPlaybookが実行できました。

$ ansible-playbook -i inventory.yml playbook.yml 

PLAY [all] *************************************************************************************************

TASK [install git] *****************************************************************************************
changed: [ec2-13-114-117-20.ap-northeast-1.compute.amazonaws.com]
changed: [ec2-35-78-213-104.ap-northeast-1.compute.amazonaws.com]
changed: [ec2-13-231-192-241.ap-northeast-1.compute.amazonaws.com]

PLAY RECAP ************************************************************************************************
ec2-13-114-117-20.ap-northeast-1.compute.amazonaws.com : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
ec2-13-231-192-241.ap-northeast-1.compute.amazonaws.com : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
ec2-35-78-213-104.ap-northeast-1.compute.amazonaws.com : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

$ 


終わりに

インベントリーファイルに、フィルターを組み合わせて使う感じで良さそう。

Cloud Operator Days Tokyo 2023 参加レポート

はじめに

Cloud Operator Days Tokyo 2023(以下、CODT2023)に、登壇とクロージングイベントへ現地参加してきました。
いくつかのセッションと現地参加の感想を記載しています。

Cloud Operator Days Tokyo - Cloud Operator Days Tokyo 2023


セッション動画の資料感想

内製開発のすゝめ〜NTT 東日本が取り組んだクラウド内製化開発の歩みと、社外展開の壁、持続可能な開発体制〜

event.cloudopsdays.com

  • 登壇者
  • 内製開発チーム作りのポイントが見どころ
    • 生成系AIを教育者とする
  • 内製開発はコスト削減に繋がらない


全面的に動的閾値監視(Anomaly Detection)を採用して分かったメリットデメリットについて

event.cloudopsdays.com

  • 登壇者
  • セブン銀行の監視の話
    • 動的閾値が向いているもの向いていないもの、具体的なフローの提示など、こちらの解釈が不要でそのまま知見を受け入れられそう
    • 実障害とそれを動的閾値で検知できたかまで記載
      • ここまで公開していてありがたい


業界初Generative AI オブザーバビリティ・アシスタント登場〜次世代AIOpsによる運用業務の変革

event.cloudopsdays.com

  • 登壇者
    • New Relic 株式会社 清水 毅さん
  • 運用業務にAIをどう活かすか活かせるかが分かりやすかったです。
    • 例えば、AIで障害解決までの時間を超短縮する
  • 動画が格好いい!


クラウドネイティブで監視は何がかわるのか? ~レストランに例えて、考えてみた~

event.cloudopsdays.com

  • 登壇者
    • 株式会社アシスト 中村 利一さん
  • 具体的にどうする?という話ではなく、概念の話
    • クラウドネイティブの監視はこう変わっていくよと、理解しやすいと思いました
    • ゴーストレストランの理解が必要


クロージングイベントの現地参加感想

現地参加のみで、ディスカッションへの参加や懇親会が開催されました。

トラブルシューティング&オブザーバビリティ(&APM

オブザーバビリティの定義

  • 既知の未知、未知の未知
    • 【既知】気づける
      • 【既知】理解できる
        • 実用的な監視  - 気づいた後に対処できる 特定の機能が使えない
      • 【未知】理解できない
        • とりあえずの監視
        • 対処できない リソース使用率が上がっている
    • 【未知】気づけない
      • 【既知】理解できる
        • 実用的な監視予備軍
        • 障害発生して後手対応になったが、次回から監視で気づける
      • 【未知】理解できない ★★ ここが対応できることがオブザーバビリティ ★★
        • 監視できていない
        • 障害発生したが減員が分からず監視もできない
          • どうするの?
            • アプリがあらゆるイベントでログをだせるようにしろ、そして取れ。解析しやすいように構造化しておけ
  • 監視をオブザーバビリティへ、レベルアップさせる

    • クラウドネイティブ環境の監視は「オブザーバビリティ」
    • 未知の未知を、既知の既知にできるか
  • QA

    • ログのストレージコストの相談は5本指に入る
      • どこまでログ取るかは試行錯誤が必要
      • 事前に予測できない、従量課金
      • 全体のインフラコストに対して、何割あてるかみたいな議論をしたほうがいいかもしれない
    • ログをLLMで解析してる?
      • XXXはやってる。モデルを作るのには、ユーザのログは使っていない(使えない)。解析に使っている
      • XXXはやってない


ハイブリッドクラウド

ハイブリッドクラウドの定義

  • 消極的と積極的がある。
  • 消極的でも積極的でもない
    • 意図があったりなかったりのそれぞれの部署がある
    • 会社の政治理由
  • プライベートクラウド
    • うまみ
      • バージョンアップのタイミングが社内調整できる
    • つらみ
      • HWが調達できない
  • パブリッククラウド
    • つらみ
      • 文化。パブクラのFWが使えず、パブクラからわざわざ社内のFWを通し、パブクラに戻すことも


クラウドセキュリティ

セキュリティ対策は何をしているか

  • セキュリティ対策
    • 現場の落とし所と現場からの正論・理想論のぶつけ合い、リスク許容・コスト観点
    • ここはやらなくていいよ集というガイドを決める
  • 基準
    • ツール基準なら、今まで使ってきて問題がないから今も使っている
  • 責任を押し付けるのではなく、共有してアドバイス貰う
    • 知らないからこそ、あなた担当だろという押しつけは散見される


モダン開発におけるAIOpsの重要な役割:ぐるなびが目指す効率的な運用戦略

完全オフラインのようなので、一部メモのみ。

  • クラウド利用における運用の変化
    • 障害発生
      • アラート通知は、開発担当にもいく
        • 開発も一時切り分けをする
    • モダン開発におけるモニタリング
      • アプリケーションは絶えず変化し続ける
        • どこのアラートが把握しにくい
        • 単一のリソースを監視しても、サービスが異常かわからない
    • どうするべきか
      • オブザーバビリティが大事
        • 運用効率化は、サービス状態の把握/可視化が第一歩
      • AIOpsの大事な役割
        • 限られた時間の中で最も不足しているのは経験
          • それをAIOpsで補完する
            • 補完するもの、運用経験において大事な側面
              • 状態の把握、傾向の分析、深い調査力
        • 最小の工数で、一人前のインフラエンジニアに仕立て上げる
  • AIOpsで大事なこと
    • マイクロサービスでは、特定のサービスの異常を検知するだけでは、原因特定が難しい時がある
      • 関連するサービスの異常を紐づける
    • 閾値監視は失敗
    • DevにOpsが入るだけでなく、OpsにもDevが入る
    • 過検出や過検知は発生する
      • 誤検知ではない
      • 最終的には経験が鍵


パネルディスカッション

AIOpsは運用のどこで使うの?使えるの?

  • AI製品を使うのではなく、裏でAIが動いていたという状態が自然
  • AIOpsによるAzureサービス品質の向上
  • 代表的な保守意見
    • ジュニアがAIを使うと危険、学習しない
  • みんなで運用に役立てよう
  • 実際に利用しての効果と課題
    • 運用コストは特に下がらない
      • 理解しようとして使う人たちだから
      • 最後に判断するのはエンジニア
    • コストは下がるけど、品質も下がるなら良くない
  • 生成系AIは使える?
    • 使える
      • ジュニアは新しいアイディアを形にできる
      • エキスパートはさらに仕事ができる
      • 間にいる人は、ただ経験が得られないだけになる?
        • 危機感を持ったほうが良い
    • ChatGPTは出来ないと回答してくれないので、ずっと質問を続けるジュニアもいる
      • 人間でも頑張って教えてくれる先輩はいたが。。。
    • 一番いいと思った例
      • 自然言語の問い合わせを、XXXQLに変換する質問
        • マーケが効果的に使っていた
          • エンジニアに分析を依頼すると、1週間とか時間がかかる
          • エンジニアは勉強すればいいというが、それが正とは限らない
  • 変化するスキルセット
    • 自分は次何をするべきか、考えられる人物が残る
    • AI適用による技術の空洞化のリスク
      • そういうものと受け入れるだけ
      • なくなる仕事はそんなにないと思うが、ものすごく生産性が高まる


所感

濃密な時間を過ごせました。内製化はどうなのか(自動化と同じで周回すると考えが変わる)、オンプレミスの解像度をあげないとだめなのではなどと考えさせられました。
また、オンラインイベントに参加していただいたのに、対面交流がなかった人達とも挨拶できてヨシ!
12月のCNDT2023もぜひ現地参加したい。

[GitHub Actions] セルフホストランナーをCloud9で試す

はじめに

GitHub ActionsをCloud9に構築したセルフホストランナーで動かしてみます。
GitHubホストランナーは利用時間の制限(無料/有料)があったり、OSの種類が決まっていますが、
セルフホストランナーは自身で用意するため、制限はなくカスタマイズも自由です。

GitHub Actions を理解する - GitHub Docs セルフホステッド ランナーの概要 - GitHub Docs



セルフホストランナーの追加手順

1. プライベートリポジトリの作成

適当なリポジトリをPrivateで作成します。

2. Agentマシンの構築

今回はCloud9を使用します。
Cloud9をインスタンスタイプ「t2.micro」、Platform「Ubuntu Server 18.04 LTS」で立てます。
セキュリティグループはデフォルトそのままでも大丈夫です。インバウンドルール、アウトバウンドルールともに何か追加する必要はありません。

セルフホステッド ランナーの概要 - GitHub Docs


3. セルフホストランナーの追加

追加したいリポジトリのメニューをたどっていくと、OSごとにセルフホストランナーを追加するコマンド手順が表示されます。
コマンドにはトークンも記載されているため、改変する必要はなく、コピペで済みます。

上部メニュー[Settings] -> 左サイドメニュー[Actions] -> [Runners] -> [New self-hosted runner]

自己ホストランナーの追加 - GitHub Docs

Linuxの例

**Download**
# Create a folder
$ mkdir actions-runner && cd actions-runner
# Download the latest runner package
$ curl -o actions-runner-linux-x64-2.303.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.303.0/actions-runner-linux-x64-2.303.0.tar.gz
# Optional: Validate the hash
$ echo "e4a9fb7269c1a156eb5d5369232d0cd62e06bec2fd2b321600e85ac914a9cc73  actions-runner-linux-x64-2.303.0.tar.gz" | shasum -a 256 -c
# Extract the installer
$ tar xzf ./actions-runner-linux-x64-2.303.0.tar.gz

**Configure**
# Create the runner and start the configuration experience
$ ./config.sh --url https://github.com/mito-201/リポジトリ名 --token ******************
# Last step, run it!
$ ./run.sh


run.shを実行すると、以下のようにGitHubと接続されたメッセージが表示され、[Runners]にも追加されます。

$ ./run.sh 

√ Connected to GitHub

Current runner version: '2.303.0'
2023-05-05 16:35:39Z: Listening for Jobs


ランナーのステータス

ステータスは次のいずれかです。

  • Idle
    • ランナーはGitHubに接続されており、ジョブを実行する準備ができています。
  • Active
    • ランナーは現在ジョブを実行しています。
  • Offline
    • ランナーは GitHub に接続されていません。
    • マシンがオフライン、セルフホストランナー上でアプリケーションが実行されていない、アプリケーションがGitHubと通信できない可能性があります。


ワークフローの作成手順

GitHub Actions を理解する - GitHub Docs

1. ディレクトリの作成

ワークフローファイルを格納するためのディレクト.github/workflowsを作成します。


2. ワークフローファイルの作成

ディレクト.github/workflowsに、以下のファイル内容でgithub-actions-demo.ymlを作成します。

  • ワークフローのトリガー
    • branches: [ "main" ] へのpush
    • branches: [ "main" ] へのpull_request
  • runs-on: [self-hosted]
    • ワークフローを実行するランナーのラベルを指定します。

GitHub Actions のワークフロー構文 - GitHub Docs


# This is a basic workflow to help you get started with Actions
name: CI

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the "main" branch
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: [self-hosted]
    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v3

      # Runs a single command using the runners shell
      - name: Run a one-line script
        run: git --version

      # Runs a set of commands using the runners shell
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.


3. ワークフローの実行

github-actions-demo.ymlをmainブランチにプッシュした際、すでにワークフローが実行されています。
上部メニュー[Actions]より、ワークフローのログが確認できます。


その他

セルフホストランナー上のコンテナでワークフローを動かしたい

GitHub Actions のワークフロー構文 - GitHub Docs

以下のように、container: image: ****と動かしたいコンテナイメージを記載します。

    runs-on: [self-hosted]
    container:
      image: bitnami/git


step単位でコンテナを指定することもできます。

    steps:
      - name: My first step
        uses: docker://alpine:3.8


セルフホストランナーのアプリケーションをサービスとして設定する

セルフホストランナーアプリケーションをサービスとして設定する - GitHub Docs

run.shと同じフォルダにあるスクリプトsvc.shを、目的に合う引数で実行します。

# インストール
$ sudo ./svc.sh install

# スタート
$ sudo ./svc.sh start

# ステータス確認
$ sudo ./svc.sh status


GitHubで利用されているIPアドレスを確認する

以下のメタ情報で確認できます。

About GitHub's IP addresses - GitHub Docs

https://api.github.com/meta