みなさんお久しぶりです。技術本部インフラストラクチャーDivの中嶋です。
最近はめっきりDeadlockという開発中のゲームにハマっています。
さて、今回私が執筆する内容はCentOS7のEOLを目前に、私たちのチームでオンプレミスサーバーのIaC（Infrastructure as Code）化に取り組んだ話となります。
特に、Ansibleを使ったサーバー構築の自動化にチャレンジすることとなり、その過程で多くの議論と学びが生まれました。
今回は、その経験と苦労、そしてAnsibleを活用して得た成果についてお話させていただきます！
プロジェクト背景とAnsible化の理由
CentOS7のEOLにより、サーバーのリプレイスが急務となりました。
私たちインフラチームが管理していたサーバーは、本番・テスト系のDNSやNTP、Baculaサーバー、メール関連サーバーなど多岐にわたります。
これらのサーバーの手作業による再構築は、膨大な時間と労力を必要とします。
今後のために、AnsibleによるIaC化を選択しました。
Ansibleは一度セットアップすれば、次回以降のサーバー構築が非常にスムーズになるため、私たちはこの機会をAnsibleの導入に活かすことにしました。
Ansible初心者が挑戦したこと
私自身、Ansibleを使うのは今回が初めてでした。
これまでに勉強会などで軽く触った経験はありましたが、本格的にコードを書くのはこのプロジェクトが初めてでした。
Ansibleのベストプラクティスやフォルダ構成を参考にしながら、試行錯誤を繰り返しました。
まず手を付けたのはテスト環境のDNSサーバーのAnsible化でした。
しかし、過去に在籍していたメンバーが構築したサーバであり、当時の管理体制上、構築をはじめとした資料は何も残っていませんでした。
そのため、ネットワークの仕様や環境の詳細が不明瞭で、最初の一歩を踏み出すのに時間がかかりました。
そんな中でも、Ansibleの構成や内容においては、チームでの議論が非常に有効でした。
例えば、Ansibleのフォルダ構成について「ベストプラクティスに従いすぎると複雑になりすぎる」という意見も出ました。
結果、シンプルで管理しやすいフォルダ構成を採用し、複雑化を避ける方向に落ち着きました。
苦労した点
Ansibleを使い始めた当初は、スムーズに進むことはありませんでした。
まず、Ansible特有のYAML形式の記述や、構成の考え方に慣れるのが大変でした。
また、初めての実装ということもあり、チーム内での認識合わせに多くの時間を費やしました。
フォルダ構成や役割分担、Ansibleのベストプラクティスに基づいた実装方法など、議論が絶えませんでした。
初期段階で議論が活発に行われたおかげで、2回目以降の実装はスムーズに進むようになりました。
最初に着手したDNSサーバのコード化が完了した後は、同様のテンプレートを用いてNTPやメールサーバーのIaC化が迅速に進みました。
初期の議論と試行錯誤のおかげで、コードの再利用性が高まり、効率が格段に向上しました。
結果と今後の展望
現時点で、今回のプロジェクトで移行したサーバーの100%をAnsible化することに成功しています。
一部のサーバー、特に「秘伝のサーバー」と呼ばれるような古いシステムに関しては構築資料も乏しく、完全なコード化は困難でした。
しかし、綿密に調査を進め、なんとかGitでの管理やAnsibleを経由した設定変更を通じて運用が改善されつつあります。
Ansible化を進めることで、私自身もAnsibleの理解を深めることができましたし、チーム全体での知識共有が促進されました。
今回のプロジェクトで得た知見やテンプレートは、今後の運用や新しいプロジェクトでも役立つと確信しています。
また、コード化することによる安心感も大きな収穫です。
今後、他のメンバーがサーバーを触る際にも、コードを読むだけで理解できる状態が整ったため、将来の保守性が向上しました。
最後に
今回のAnsible化プロジェクトは、単にサーバー構築の自動化をするだけでなく、チームとしての成長や知識の共有にも大きく貢献しました。
最初は議論や試行錯誤の連続でしたが、それが結果的にチーム全体のスキルアップと効率化につながりました。
IaC化を進めたいと考えている方々にとって、Ansibleの導入は少々敷居が高いと感じるかもしれませんが、チームで議論しながら進めることで、確実に成果が得られると実感しています。
今後は複雑なサーバーやシステムにもAnsibleを適用し、さらなる自動化と効率化を目指していきたいと思います。
みなさまもよきAnsibleライフをお過ごしください！
