mito’s blog

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

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 2024


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

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

www.youtube.com

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


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

www.youtube.com

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


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

www.youtube.com

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


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

www.youtube.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

[Ansible][Terraform]AnsibleとTerraformのModuleの違い

AnsibleとTerraformには、Moduleと呼ばれる機能があります。
ただし、名前が同じなだけで内容は異なります。

概要 Ansible Terraform
コードの要素 Module タスクの単位  Resource リソースの単位 
再利用可能なコードの単位 Role  タスクの集合  Module  リソースの集合 


AnsibleのModuleとTerraformのResource

どちらもリソースの構築や設定を行うコードの要素です。


  • Ansible

AnsibleのModuleは、Playbookのtasksに記載するコードの単位です。
ターゲットノードに、Moduleの処理内容を実行します。
以下の例では、ローカルホストに、yumモジュールでhttpdの最新版をインストールします。

- hosts: localhost
  
  tasks:
    - name: Install the latest version of Apache
      ansible.builtin.yum:
        name: httpd
        state: latest


  • Terraform

TerraformのResourceは、TFファイルに記載するコードの要素です。
Terraformで構築するリソースを記載します。
以下の例では、AWSのEC2インスタンスを、マシンイメージはUbuntuインスタンスタイプはt3.micro、インスタンス名はHelloWorldで構築します。

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"

  tags = {
    Name = "HelloWorld"
  }
}



AnsibleのRoleとTerraformのModule

どちらもコードを再利用可能な形で外に切り出したものです。
プログラミングで言う関数のようなものです。


  • Ansible

AnsibleのRoleは、タスクや変数ファイル、ハンドラーなどを再利用可能な形で、仕様に基づいたディレクトリやファイル構造に分割したものです。
Roleのタスクを参照することで、Roleの変数ファイル、ハンドラーなどを自動的に読み込みます。
以下の例は、再利用可能な形にしたcommonロールをPlaybook.ymlで呼び出すディレクトリ・ファイル構造です。

$ tree
.
├── playbook.yml
└── roles
    └── common
        ├── handlers
        │   └── main.yml
        ├── tasks
        │   └── main.yml
        └── vars
            └── main.yml

5 directories, 4 files


  • Terraform

TerraformのModuleは、リソースを再利用可能な形で外に切り出したものです。
カレントディレクトリのTFファイルで、Moduleディレクトリ内にあるTFファイルの実行結果を参照します。
以下の例は、再利用可能な形にしたcommonモジュールをカレントディレクトリのTFファイルで呼び出すディレクトリ構造です。

$ tree
.
├── modules
│   └── common
│       └── main.tf
├── output.tf
├── terraform.tf
└── variable.tf

2 directories, 4 files