ラズパイにAWXとGitLabを入れて快適な自宅Playbook実行環境を作る

2024年12月9日 09:00

こちらは、公式アドベントカレンダー2024【A】IT技術関連トピック Day.9 の記事です。
公式アドベントカレンダー2024【B】仕事術・キャリア・体験記も毎日記事を公開していますので、ぜひあわせてご覧下さい。

★Day8のアドベントカレンダー記事
devcontainerでBun+React+Vite構成のフロントエンド開発環境を構築する（矢坂拓）

ITソリューション部の水谷です。

みなさんはラズパイ（Raspberry Pi＝ARMプロセッサを搭載した小型シングルボードコンピューター）はお持ちですか？

ラズパイは、プログラミングや、様々なプロトコルによるデバイスとの通信などの学習用に作られた超小型PCであり、初期バージョンは性能が低かったものの、バージョンが上がるごとに劇的に高性能化してきました。2024年1月に発売が開始された最新版の Raspberry Pi 5では、CPU が Cortex-A76の 2.4GHzになり、メモリも（最大のもので）8GBと潤沢にある上、PCIeを搭載し、Wi-FiもGigabitEtherも持っています。ここまでくると、もう学習用途だけでなく、家庭用小型サーバーとして使えるほどの性能と言えるかもしれません。

photo：Raspberry Pi 5 オフィシャルページに掲載されている画像

私も（ずっと前になりますが）Raspberry Pi 2がブームの時は私物として1台持っていましたし、とある会社のプロジェクトで、Raspberry Pi 2を使ってあるデバイスをコントロールするコードを書いたこともありました。

その後新しいバージョンの Respberry Piを使う機会はなかったのですが、少し前にネットでラズパイを複数台使ってKubernetes環境を作って活用している例なども見て、もしかしたら最新のラズパイが1台あれば、快適な家庭用 Ansible環境が作れるんじゃないかな、と思い、トライしてみることにしました。

結果としてはなかなか良い感じになったので、記事として残しておこうと思います。

おうちAnsible環境に欲しいもの

まず、どんな構成の環境を作るかですが、とりあえず最低でも Playbook の実行プラットフォームとして、AWXを動かしたいところです。AAP（Ansible Automation Platform）の開発者用サブスクを取得するという手も考えたのですが、AAPはx86-64アーキテクチャのRHEL上にしかインストールできないので、Raspberri Piにはインストールできないため諦めました。

そして、ソースコード管理ツールも入れたいところですが、候補としては定番の GitLabか、あとは軽量な Giteaとかもいいかな、あるいは使ったことがないものを試してみようかな、といろいろ迷ったのですが、仕事でもGitLab はよく使うので勉強しておきたいし、ネットに情報もたくさんあるので、一旦 GitLab で行こうかなと思います（なお、GitHub Enterprise Serverも少し調べてみましたが、有償で、試用期間は45日と短いため、候補から外しました）。あと、CI/CDでansible-lintを実行したいので、GitLab Runnerもラズパイ上で動かしたいところです。

それ以外は、監視系ツールとかも考えたのですが、とりあえず AWX＋GitLab＋Runnerがあれば十分遊べるかなと思いますので、今回は欲張らずにこの構成で進めます。

どう建てるかの検討

前回の記事で、軽量な Kubernetesディストリビューションである "K3S"でコンテナ環境を作って、そこにAWXをデプロイする方法を書きましたので、まずはそれを試しました。

※OSはRaspberry Pi OSではなく、Ubuntu 24.04LTS Serverを使っています。

きっといろいろトラブルが発生するのではないかなと考えていたのですが、AWXは2年くらい前からARMプロセッサの対応を進めていたようで、AWX Operatorを使えばx64環境と同じようにデプロイができました。

しかし、GitLabについては一筋縄ではいきません。まず、GitLabはHelm Chartでデプロイすることがポピュラーなようなので、これを試してみました。が、複数のPodがCrashLoopBackOffになってしまい、解決を試みたのですが（私の知識では）無理でした。

続いて、Operatorを使ったインストールを試したのですが、（試行錯誤した結果）なんとかインストール自体はできたものの、搭載メモリ8GBをすべてを使いつくし、スワップが大量発生する事態となってしまいました。。。

ストレージが micro SDカードなのでスワップ自体も遅く、この状況ではまともに使えません。

Raspberry Pi 5には PCIeがあるので、NVMeのSSDを使えばスワップの速度は改善されますが、まだ Runnerのコンテナも動かしていない状態でこれではちょっと無理があるな、と感じました。

そこで、K3S環境に建てるのは諦めて、AWXについては昔からある docker-composeを使ったインストールにし、GitLabもdockerで動かすことでメモリ使用量を抑えられないかと思い、試してみることにしました。

Docker ComposeでAWX 24.6.1を動かす

ということで、まずはAWXから行きましょう。

事前準備として、AnsibleとDocker、Docker Compose、docker-buildx、そしてmakeをインストールします。また、一般ユーザーからdockerコマンドを実行できるようにしておきます。

$ sudo add-apt-repository ppa:ansible/ansible -y
$ sudo apt update
$ sudo apt upgrade -y
$ sudo apt install ansible docker.io docker-compose docker-buildx make -y
$ sudo docker buildx install
$ sudo gpasswd -a $USER docker

上記コマンドを実行したのち、一度ログアウトして、ログインし直します。

さて、AWXのDocker Composeでのインストールは、基本的にGitHubにあるコードをクローンして、makeでコンテナビルドを行い、さらにmakeでdocker-composeファイルを生成して、それを実行するという流れになります。

まずはクローン。

$ git clone https://github.com/ansible/awx

今回は執筆時点での最新バージョンであるバージョン24.6.1をビルドしたいと思いますので、このタグでチェックアウトします。

$ cd awx
$ git checkout 24.6.1

で、コンテナのビルドはmakeコマンドを "docker-compose-build" オプションで実行すればよいのですが、実際にやってみるとエラーが出ます。

エラーメッセージを詳しく見ると、これらはCPUがARMだからではなく、使用しているライブラリが（すでに削除されていて）ダウンロードできなかったり、ライブラリの機能が変わっていて互換性がなくなっているためでした。

具体的には、makeを実行するとリポジトリ内にあるPlaybookが実行され、そこにあるテンプレートからDockerfileが生成されるのですが、生成されたDockerfileを見ると、opensslのバージョン3.0.7をインストールするようになっています。ところが、数か月前にOpenSSLにセキュリティ問題が見つかって、このバージョンがダウンロードできなくなっていたのです。これを解決する方法として、セキュリティ問題が解決されているバージョン3.2.2（特にこのバージョンが推奨されているわけではなく、あくまで動作の確認ができたバージョンになります）に変えることにしました。

変更するファイルは、tools/ansible/roles/dockerfile/templates/Dockerfile.j2 で、2か所あるのでどちらも変更します。

…
# Install build dependencies
RUN dnf -y update && dnf install -y 'dnf-command(config-manager)' && \
    dnf config-manager --set-enabled crb && \
    dnf -y install \
    iputils \
    gcc \
    gcc-c++ \
    git-core \
    gettext \
    glibc-langpack-en \
    libffi-devel \
    libtool-ltdl-devel \
    make \
{% if not headless|bool %}
    nodejs \
{% endif %}
    nss \
    openldap-devel \
    # pin to older openssl, see jira AAP-23449
    openssl-3.0.7 \　　　　　　　　　＜ーーーーーーーここともう１か所を変更
    patch \
    postgresql \
    postgresql-devel \
…

また、requirements/requirements_git.txtに書かれているdjango-ansible-base も、デフォルトのdevelを使うとエラーが出たので、少し古いですが 2024.7.17のタグのものを使うことにしました。

django-ansible-base @ git+https://github.com/ansible/django-ansible-base@2024.7.17#egg=django-ansible-base[rest_filters,jwt_consumer,resource_registry,rbac]

これでmakeが成功するはずです（10分程度かかります）。

$ make docker-compose-build

エラーが出ずにビルドが完了したら、docker imagesでイメージができているか確認します。

$ docker images
REPOSITORY                  TAG       IMAGE ID       CREATED             SIE
ghcr.io/ansible/awx_devel   HEAD      f899f23e0c08   About an hour ago   2.1GB

続いてdocker-compose.ymlファイルを生成してAWXの起動までを行うmake docker-composeを実行するのですが、docker-compose.ymlの生成だけをやってほしく、起動は自分でやりたいので、起動しないようMakefileを変更します。

具体的には、Makefileの中で$(MAKE) docker-compose-upと書かれている行をコメントアウト（あるいは削除）すればOKです。

この変更を行った後に、下のようにmakeを実行すれば /tools/docker-compose/_sources/docker-compose.ymlが生成されます。

$ make docker-compose

一度AWXを起動してみます。

$ docker-compose -f tools/docker-compose/_sources/docker-compose.yml up -d
Creating network "awx" with the default driver
Creating network "service-mesh" with the default driver
Creating volume "tools_awx_db_15" with default driver
Creating volume "tools_redis_socket_1" with default driver
Pulling redis_1 (redis:latest)...
latest: Pulling from library/redis
83d624c4be2d: Pull complete
473c53d52ee8: Pull complete
6f2cf6cf0e56: Pull complete
e5799663249b: Pull complete
8e3fc4377a6e: Pull complete
cedf876e65f7: Pull complete
4f4fb700ef54: Pull complete
3aa9d59b5200: Pull complete
Digest: sha256:a06cea905344470eb49c972f3d030e22f28f632c1b4f43bbe4a26a4329dd6be5
Status: Downloaded newer image for redis:latest
Pulling postgres (quay.io/sclorg/postgresql-15-c9s:)...
latest: Pulling from sclorg/postgresql-15-c9s
f35e2140698f: Already exists
742da9cbbe4d: Pull complete
12e2795759d4: Pull complete
Digest: sha256:c242f8fc1483928ee72803ac5345814601e4f5b3f8758181104e390d848976b3
Status: Downloaded newer image for quay.io/sclorg/postgresql-15-c9s:latest
Creating tools_postgres_1 ... done
Creating tools_redis_1    ... done
Creating tools_awx_1      ... done

最後の3行から各コンテナインスタンスが正しく作られたように見えます。めでたしめでたし、と思いきや、docker logs tools_awx_1でログを見てみると、下のようなrsyslogdに関するメッセージが連続して出力されていました。

2024-11-10 05:08:07,242 INFO spawned: 'awx-rsyslogd' with pid 1691
rsyslogd: could not open config file '/var/lib/awx/rsyslog/rsyslog.conf': Permission denied [v8.2102.0-106.el9 try https://www.rsyslog.com/e/2104 ]
rsyslogd: run failed with error -2104 (see rsyslog.h or try https://www.rsyslog.com/e/2104 to learn what that number means)
2024-11-10 05:08:07,259 INFO success: awx-rsyslogd entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
awx-rsyslogd stderr | rsyslogd: could not open config file '/var/lib/awx/rsyslog/rsyslog.conf': Permission denied [v8.2102.0-106.el9 try https://www.rsyslog.com/e/2104 ]
awx-rsyslogd stderr | rsyslogd: run failed with error -2104 (see rsyslog.h or try https://www.rsyslog.com/e/2104 to learn what that number means)
awx-rsyslogd stderr |
2024-11-10 05:08:07,259 WARN exited: awx-rsyslogd (exit status 1; not expected)

何が問題なのかよくわからなかったのですが、検索すると以下のIssueが引っかかります。

https://github.com/ansible/awx/issues/14259

これによるとrsyslogdのapparmor profileをdisableにすればよい、とのことなので書かれた通りにやってみます。

sudo ln -s /etc/apparmor.d/usr.sbin.rsyslogd /etc/apparmor.d/disable/
sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.rsyslogd

AWXのコンテナをdocker-compose downで一度落として、再度upしたところ、正常に動くようになりました。

もう一度tools_awx_1コンテナのログを表示させると、ランダムに生成された adminユーザーのパスワードが確認できますので、忘れずにメモっておきます。

$ docker logs tools_awx_1
WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers
[ -d "/awx_devel/awx.egg-info" ] || python3.11 /awx_devel/tools/scripts/egg_info_dev
mkdir -p /var/lib/awx/; \
if [ "/var/lib/awx/venv" ]; then \
        . /var/lib/awx/venv/awx/bin/activate; \
fi; \
python3.11 -c "import awx; print(awx.__version__)" > /var/lib/awx/.awx_version; \

if [ "/var/lib/awx/venv" ]; then \
        . /var/lib/awx/venv/awx/bin/activate; \
fi; \
awx-manage migrate --noinput
Operations to perform:
  Apply all migrations: auth, conf, contenttypes, dab_rbac, dab_resource_registry, main, oauth2_provider, sessions, sites, social_django, sso
Running migrations:
  No migrations to apply.
Admin password: isutlJnVqMfBXnCZlLlW   <---- ここ
(changed: False)
(changed: False)
Successfully registered instance awx-1

続いてAWXのUIのビルドです。これは、tools_awx_1コンテナの中でmakeを実行すればやってくれます（8分ほどかかります）。

$ docker exec tools_awx_1 make clean-ui ui-devel

ビルドが終われば、（同じネットワーク内にいるマシンの）ブラウザから https://<raspberry pi のIPアドレス>:8043でAWXにアクセスできるはずです。

デモジョブテンプレートを実行してみると、下のように成功したので、EE（awx-ee:latest）もpullでき、動作したようです。

※デフォルトでは自己署名証明書が使われていますので、ブラウザでアクセスすると下のような警告が出ます。「詳細設定」をクリックして「192.168.1.12 にアクセスする（安全ではありません）」などと書かれているリンクをクリックすればアクセスできます。

GitLabをコンテナで動かす

続いてGitLabです。

GitLabは先ほど書いたようにKubernetes環境にはHelmでインストールすることもできますし、Operatorもあります。また、非コンテナ環境には（リポジトリを追加して）apt-getでインストール可能。そして、もう1つの方法として、公式dockerイメージをPullして動かすこともできるようになっています。

K3S環境はあきらめたものの、AWXがコンテナで動いているならこちらもコンテナで、ということでGitLabはdockerを使って、AWXと同じネットワーク内で動かそうと思います。

と書いたものの、ここに１つ落とし穴が。というのも、docker pull gitlab/gitlab-ceでPullできるオフィシャルのイメージは、x86-64アーキテクチャ用のものしかありません。ダメ元で試しにPullして実行してみたところ、やはり動きませんでした。

で、いろいろ検索してみると、個人が作成したARM用GitLabコンテナイメージが公開されているのを見つけました。

https://hub.docker.com/r/zengxs/gitlab/tags

今回はここにある、GitLab-ceのバージョン17.5.1を使わせていただくことにします。

ちなみに、このビルドを作成するのに使ったDockerfileを公開している GitHubリポジトリもこちらにありました。

https://github.com/zengxs/gitlab-arm64

簡単に調べてみると、"GitLabの実行に必要な様々なサービスやツールをパッケージ化し、多くのユーザーが手間のかかる設定なしにインストールできるようにしたもの" である "Omnibus GitLab" のDockerfileを素直にARMアーキテクチャに対応させたもので、怪しい箇所も見当たらなかったので、使って問題ないと判断しました。

試しにこのDockerfileで GitLab-CE 17.5.1をビルドしてみたところ、問題なくビルドできることを確認しました。もしイメージが公開されていないバージョンを使いたい場合は、このDockerfileを使って自分でビルドすることも可能ということになりますね。

さて、起動の前にマウントするボリュームとして、以下のディレクトリを作成しておきます。

/etc/gitlab
/etc/gitlab/config
/etc/gitlab/logs
/etc/gitlab/data

そして、起動コマンドですが、こんな感じにしました。

docker run -d --hostname gitlab --publish 8143:443 --publish 80:80 --publish 2122:22 --name gitlab-container --volume /etc/gitlab/config:/etc/gitlab:Z --volume /etc/gitlab/logs:/var/log/gitlab:Z --volume /etc/gitlab/data:/var/opt/gitlab:Z --net awx zengxs/gitlab:17.5.1-ce

家の中だけで使う前提なので、Web UIやAPIには、httpsではなくhttp（ポート番号80）でアクセスすることにします。また、前述のように--net awxとして、AWXのネットワーク上で動かすようにしています。

これを実行するのですが、コンテナイメージをPullしますので、少々時間がかかります。

$ docker run -d --hostname gitlab --publish 8143:443 --publish 80:80 --publish 2122:22 --name gitlab-container --volume /etc/gitlab/config:/etc/gitlab:Z --volume /etc/gitlab/logs:/var/log/gitlab:Z --volume /etc/gitlab/data:/var/opt/gitlab:Z --net awx zengxs/gitlab:17.5.1-ce
Unable to find image 'zengxs/gitlab:17.5.1-ce' locally
17.5.1-ce: Pulling from zengxs/gitlab
a186900671ab: Pull complete
05fda59ce3ae: Pull complete
b5ce4bc990e9: Pull complete
8cbb958b0a47: Pull complete
68fd519ab599: Pull complete
605537abdaaa: Pull complete
3cfdb1f4d6fd: Pull complete
eda397460dc5: Pull complete
fd97ed6b5229: Pull complete
Digest: sha256:61cb4c79fe55de9dc94822d5a64a07ee40ff681d6282ab5733bc8e80479451ff
Status: Downloaded newer image for zengxs/gitlab:17.5.1-ce
ee0473aa44f5812b2cae28f33bef24b3df59982d69cf7ba27110237cd89d5537

無事起動しましたら、/etc/gitlab/configディレクトリに "initial_root_password" というファイルができているはずです。その名の通り、ファイル内にrootユーザーのパスワードが書かれているので、メモします。

あとは、さらにしばらく待ってからWebブラウザでアクセスしてみると、GitLabのログイン画面が表示されます。

GitLab Runnerもコンテナで動かす

GitLab Runnerに関してはARMアーキテクチャ用のコンテナがオフィシャルから公開されていますので、これを使用します。

あらかじめ /etc/gitlab/runnerディレクトリを作成しておき、以下のように起動します。

$ sudo mkdir /etc/gitlab/runner
$ docker run -d --name gitlab-runner -v /etc/gitlab/runner:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock --net awx gitlab/gitlab-runner:latest
Unable to find image 'gitlab/gitlab-runner:latest' locally
latest: Pulling from gitlab/gitlab-runner
1b9f3c55f9d4: Pull complete
6f639a3e655c: Pull complete
d55be237d1a8: Pull complete
Digest: sha256:d7776fd6b38f5d985832a6fde36062fb74ff38f5000d25d7843a2e3486b6d277
Status: Downloaded newer image for gitlab/gitlab-runner:latest
22ae7c68468033c7c7469a8413d8a7aca8389c4fdbe1779d0570d45a31d0b57e

続いてRunnerの設定を行うのですが、そのためにはRunnerをGitLabに登録するために必要な "Registration Token" を取得する必要があります。

GitLabのWebUIで、"Admin" ボタンを押し、左メニューの "CI/CD" → "Runners" を選択。右上の "New Instance Runner" の右にある「…」をクリックするとRegistration Tokenが取得できます。

その後、Runnerのコンテナ内でgitlab-runner registerを実行すれば、runnerの設定ができます。

$ docker exec -it gitlab-runner gitlab-runner register
Runtime platform                                    arch=arm64 os=linux pid=43 revision=12030cf4 version=17.5.3
Running in system-mode.

Enter the GitLab instance URL (for example, https://gitlab.com/):
http://gitlab/
Enter the registration token:
AXF1tC-q3Tj2Vs_3WS3K
Enter a description for the runner:
[22ae7c684680]: Arm Runner
Enter tags for the runner (comma-separated):

Enter optional maintenance note for the runner:

WARNING: Support for registration tokens and runner parameters in the 'register' command has been deprecated in GitLab Runner 15.6 and will be replaced with support for authentication tokens. For more information, see https://docs.gitlab.com/ee/ci/runners/new_creation_workflow
Registering runner... succeeded                     runner=AXF1tC-q
Enter an executor: shell, parallels, virtualbox, docker-windows, docker+machine, instance, custom, docker, kubernetes, docker-autoscaler, ssh:
docker
Enter the default Docker image (for example, ruby:2.7):
ghcr.io/ansible/community-ansible-dev-tools:latest
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

Configuration (with the authentication token) was saved in "/etc/gitlab-runner/config.toml"

GitLabのURL、先ほど取得したToken、Runnerの説明、Tag（今回は指定なし）、Runnerの種類は "docker"、イメージはansibleやansible-lintなどがインストールされている "ghcr.io/ansible/community-ansible-dev-tools:latest" と指定して登録を行いました。

GitLabのWeb UIに戻って、Instance runnerのページをリロードすると、以下のように先ほど登録したRunnerが表示され、登録できていることが確認できます。

ここで１つ問題があって、このRunnerのインスタンス（gitlab-runner コンテナの中で動作する community-ansible-dev-tools のインスタンス）から、GitLabへの名前解決ができません。

そこで、runnerの設定ファイル /etc/gitlab/runner/config.toml に、以下の行を追加します。

  extra_hosts = ["gitlab:192.168.1.12"]

これで、community-ansible-dev-tools のインスタンスからGitLabにアクセスができて、リポジトリのクローンができるようになります。

出来上がったシステムを使ってみる

動かしたいコンテナがすべて起動したので、簡単に動作確認をしてみたいと思います。

まずは、リポジトリの作成です。GitLabにログインして、ホームから "Create New Project" をクリックして、下のように "TestProject" というリポジトリを作成しました。

リポジトリ内にPlaybookを１つ作ります。

test_playbook.yml

---
- name: Test Play
  hosts: localhost
  gather_facts: false
  tasks:
    - name: Debug
      ansible.builtin.debug:
        msg: "Hello from ARM AWX"

あと、ansible-lintを実行するだけのシンプルなCI/CDの定義ファイルを作成します。

.gitlab-ci.yml

stages:
  - lint

syntax-check:
  stage: lint
  script:
    - ansible-lint

これらをcommit/pushすると……。

期待通りCI/CDパイプラインで定義したansible-lintが実行されました。

続いてAWXの設定ですが、まずはGitLabにアクセスするための認証情報を下のように作ります。

そして、プロジェクトを下のように作成（同じネットワーク内にいるため、GitLabにはhttp://gitlabでアクセス可能）。

今回のPlaybookはlocalhostに対する実行なので、インベントリは作成せずに、"Demo Inventory"を使うことにして、ジョブテンプレートを作成します。

実行してみると、下のように無事成功しました。

簡単ですが、GitLabとAWXの連携、およびRunnerが動作することが確認できました。

自動起動について

さて、今の状態では、ラズパイが再起動した際にはAWXもGitLabも自動的には起動しません。

このラズパイをAWXとGitLab専用機として使っていくのであれば、自動起動するようにしてと便利ですよね。

やり方としては、これまでに書いたAWXのdocker-compose upのコマンドと、GitLabとrunnerを起動するdockerコマンドを1つのシェルスクリプトに書いてしまって、それを自動実行するようにするか、docker-compose.yml内の各サービスの定義に "restart: always" を追加し、GitLabやrunnerを起動するdockerコマンドに"--restart always"を追加する、という方法もありますので、お好きな方法で設定していただければと思います（私は後者を行いました）。

まとめ

ちょっと苦労したところはありましたが、無事AWXとGitLab環境をラズパイ上に構築することができました。

気になっていたメモリ使用量も、8GBを少し下回っていて、動作にもたつきもありません。また、ストレージがmicro SDなのでファイルの読み書きの遅さも心配してましたが、Raspberry Pi 5は4よりもmicro SDの読み書き速度が倍くらいに上がっていることもあり、今のところ遅さは気になっていません。そもそもリポジトリにPushされた瞬間、あるいはAWXでジョブテンプレートが実行されているときくらいしかストレージにアクセスされないので、多少遅くてもあまり影響ないのかもしれませんね。

Raspberry Pi 5は、（電源、クーラー、ケースなどの）附属品も含めて２万円程度で購入でき、消費電力も待機時は3～4W、高負荷時でも7～8W程度と低いです。GitLabもAWXもアイドル状態になっていることが多い（コードをPushしたり、ジョブテンプレートを実行しているとき以外はほぼ何もしていない）ので、毎月の電気代もラーメン一杯分かそれ以下しかかかりません。運用コストの低さは抜群ですね！

この環境、Ansible、Git、CI/CDの学習やコンテナの学習にもなかなか良いのではないかと思います。年末年始の休みや日曜大工に構築してみてはいかがでしょう？

ちなみに、この記事を書きながら裏で全行程のPlaybook化も進めています。この記事にそれ書くとさらに倍くらいの長さになりそうなので、別のブログとして投稿しようと思います。

★公式ブロガー水谷の執筆記事一覧https://note.com/hashtag/SHIFT_%E6%B0%B4%E8%B0%B7

執筆者プロフィール：水谷裕一
大手外資系IT企業で15年間テストエンジニアとして、多数のプロジェクトでテストの自動化作業を経験。その後画像処理系ベンチャーを経てSHIFTに入社。
SHIFTグループ会社「RGA」および「システムアイ」に出向し、インフラ構築の自動化やCI/CD、コンテナ関連の業務に従事した後、2024年3月よりSHIFTのインフラサービスGに配属。
LinuxよりWindowsの方が好き。

★SHIFTグループ公式アドベントカレンダー2024【A】 IT技術関連トピック Day10は「天才くんのセキュリティとこれから」（坂瀬成俊）

IaC支援サービスのご紹介

SHIFTではTerraformやCDKを使ったクラウドインフラ構築の自動化や、Ansibleを使ったサーバOSの設定自動化や構成管理のご支援も行っております。ご依頼・ご相談は下記リンクからお願いします。

お問合せはお気軽に

SHIFTについて（コーポレートサイト）

SHIFTのサービスについて（サービスサイト）

SHIFTの導入事例

お役立ち資料はこちら

SHIFTの採用情報はこちら

PHOTO：UnsplashのShubham Dhage

最後まで読んでくださり、ありがとうございます！

御社サービスのご相談はお気軽に。

ソフトウェア品質のプロがお伺いします。