こんにちは。
技術本部 技術戦略ディビジョンでシステムエンジニアをしています山中です。
最近寒暖差が激しく、体調を崩しやすい時期になってきました。これから寒くなるので布団から出られないということがありそうです。
さて今回は3か月半行なったタスクの内容を記事にしました。
大きなタスクでしたが「全て自分でやらないといけない」と思い込んで、チームメンバーに迷惑をかけてしまったのと同時に、多くの学びを得ることができました。
弊社ではソースコード管理の一部をGitLab Self-Managed版(以下GitLab)を使用しています。
もともとGitLabはオンプレミスで運用しておりましたがクラウド移行しました。
その際にEC2インスタンス上のOSはCentOS7が採用されましたがEoLを迎えることもあり、今回Amazon Linux 2023へ移行しました。
今回はその移行作業における奮闘記を記述します。
EoL対応タスクの詳細
ゴール
GitLabをCentOS7からAmazon Linux 2023へ移行し、社内へサービス提供ができるようになること。
前提
既存の環境の理解不足とその背景
運用されているGitLabの構成について、タスク計画の時点では全く把握をしておらず、運用やメンテナンス作業も行ったことはありませんでした。
IaCの1つであるAnsible（Ansible Moleculeを含む）も触ったことが無いため、Ansibleの知見を学びながら、サーバー移行の方法を調査しながらタスクを進めていく想定でした。
そのため自分にとって未知なタスクに挑戦する気持ちで挑戦しました。
タスク内容
今回の作業内容の一部抜粋を以下に箇条書き形式で記述しています。
- Amazon Linux 2023上のEC2インスタンスでGitLabをインストール・設定・起動するAnsible Playbooksの作成
- GitLabのアップグレード
- 15.11.13 → 16.3.7
- GitLabを起動しているEC2のOSをCentOS7からAmazon Linux 2023へ移行(データ移行も含む)
以下にそれぞれの作業内容についてタスク内容と押さえるべきポイントをまとめました。
Amazon Linux 2023のEC2に実行させるのAnsibleコード作成
タスクの内容
Amazon Linux 2023で構築したEC2に対して実行させるAnsibleのコードを作成しました。
すでにCentOS7に実行させるAnsibleのコードはあったので、それをAmazon Linux 2023に実行できる必要がありました。
押さえるべきポイント
CentOS7とAmazon Linux 2023では下記の違いがありました。
- パッケージインストール方法が異なる
- yumからdnf
- デフォルトでインストールされているパッケージが異なる(一例)
- cronを追加でインストール
仕様に異なりがあるためAnsibleをそのままでは実行できませんでした。
そのためモジュールを変更やパッケージをインストールするモジュールを追加しました。
OS変更に伴い、AnsibleとMoleculeの修正も必要になりました。
EC2 AMI変更やデフォルトユーザ名などの修正し、AnsibleとMoleculeの実行を確認しました。
GitLabサーバーのアップグレード
タスクの内容
CentOS7で構築していた変更前のGitLabサーバーのバージョンを15.11.13から16.3.7にアップグレードしました。
押さえるべきポイント
Amazon Linux 2023では、調査した時点でGitLabのバージョン15.11.13がサポートされていないことがわかりました。
画像を読み取ると、Amazon Linux 2023は16.3以降だとサポートされています。
調査した時点で15.11.13から16系の最新を確認するためにアップグレードパスのページを確認しました。
下記画像は調査した時点での表示されていた画像です。
今回はアップグレードパスで提示されている16.3.7をターゲットにしました。
16.3.7にアップグレードをするにあたり、廃止される機能ややるべきことをリストアップ&社内のエンジニアに全体周知しました。その後CentOS7で構築していた変更前のGitLabサーバーのバージョンを15.11.13から16.3.7にアップグレードが完了しました。
GitLabを起動しているEC2のOSをCentOS7からAmazon Linux 2023へ移行(データ移行も含む)
タスクの内容
EC2でGitLabを構築しており、データベースもそのEC2で構築していました。そのため既存のデータ移行するとき、EC2からDBバックアップやGitデータなどをS3へアップロードしました。そのデータをAmazon Linux 2023で構築したEC2のGitLabにデータをリストアしています。
現状の構成は以下のようになっていました。
- EC2インスタンス
- GitLab
- PostgreSQL
- Redis
各種ミドルウェアもEC2内に構築し、手動でバックアップ、エクスポートをする必要があります。
切り替え前の事前準備としてPostgreSQLのバックアップ、GitデータなどをS3へアップロードを行う必要がありました。
切り換え時にAmazon Linux 2023上に構築されたGitLabに対して各種データをリストアする必要があります。
押さえるべきポイント
公式ドキュメントにマイグレーションの方法が書いています。
上記を参考に移行手順書を作成後、テスト環境で何度もリハーサルを行うことで実行手順が正しいことの確認やパフォーマンスが問題ないことが確認しました。
全体の動作確認も正常ということを確認して本番環境の切り替えを実施しています。
失敗エピソード
上記タスクを進めていく上で失敗したエピソードを記述します。
ハードスキル不足による作業の遅延
AnsibleやMoleculeは未経験だったため、概念から学習しました。
情報のキャッチアップやtest環境での動作確認に苦戦したのですが、その悩みを共有しなかったことで作業が遅れました、その結果、想定以上の工数を費やしました。他にはEoLやサーバー移行に関する知識不足から重要な考慮点を見落とし、会議中に専門用語の意味が分からず、質問をためらったことも作業遅延の要因です。
改善策
作業が止まっている時こそ進捗を共有し、他メンバーの助言を得て解決することが重要です。
専門用語の意味が分からない場合はその場で確認し、わからないままにしないことで効率を上げる必要があります。ハードスキルの不足を認め、適切な報連相を通じてサポートを受けることで、よりスムーズに作業を進められると考えました。
タスクの正しい見積もりができていなく、作業に大幅な遅れが発生
当初チームでは3〜4週間で完了する見積もりでしたが、実際には3か月半もかかりました。原因はハードスキル不足から必要なタスクの把握が不十分であり、タスクの全体像を正しく認識していなかったことです。
会議に参加しても「なぜサーバー移行が必要なのか？」「この会議の目的は何か？」と疑問を持ちながら参加していたため、効率的に進められませんでした。
改善策
タスクの全体像を最初に明確にし、必要な作業を把握することで認識のズレを防ぐべきでした。会議の目的や必要性も事前に確認し、主体的にタスクを進める姿勢が求められます。
振り返り
今回のプロジェクトを通して自分の動き方や進め方に関して振り返りました。
振り返りは事実、見解、改善という流れで改善アクションを考えます。
事実
- 進捗が思うように出ず、途中で意欲が低下した結果、報告や連絡（報連相）を怠った
- 会議する必要性が分からないまま会議に参加した場面があり、会議が終わった後も確認を取らなかった
- 専門用語の意味が分からなかった単語や技術用語をその場で確認せず、作業効率が低下した
- タスクの全体像をメンバー間で認識できておらず、独自に進めた結果、求められている内容とは異なる作業をした
見解
- 進捗が遅れている場合でも、報告して共有すれば、チームメンバーからのサポートやアドバイスが得られ、作業がスムーズに進んだ可能性があった
- 「チームメンバーの時間を使ってはいけない」という思い込みが進捗を滞らせ、結果的にチーム全体の効率を下げる要因となった
- 専門用語を分からないまま放置したことで、後の作業でミスや認識違いが生じる可能性があるため、適切に確認を取るべきであった
- ハードスキル不足がタスクの遂行に影響を与え、時間がかかった
改善
- 進捗が出ていない場合でも、定期的に報連相を行い、他メンバーに状況を共有する習慣をつける
- チーム内では毎朝進捗を報告する会がありますので、そこで「困っている」という報告をして状況を伝えることを意識する
- 会議中に理解できない内容があれば、その場で積極的に質問し、認識のすり合わせを行うようにする
- 分からないままだとその会議に参加している意味がないので、その場で質問し有意義な時間になるようにする
- 会議や作業中に不明な用語が出たら、その場で確認・質問し、後々の認識違いを防ぐようにする
- タスクの開始前に、チーム全体でタスクの全体像を明確に把握し、認識のズレが生じないように、進行中も定期的に確認する
- オンラインホワイトボードツールなどを活用して図で表現し、認識が正しいかそうでないかをお互いがわかる状態にする
今回得た学び
「自分が主体的に行動し、能動的にタスクを行う」ことが大事だと痛感しました。
報連相をすることで進捗の共有や協力を依頼でき、より効率的に作業ができたのでは？と考えています。途中成果が出てないことで意欲が低下し、報連相をしないということもありました。振り返ると改善するべきことです。
今回得た学びは業務全てに関わる内容なので、今後も報連相の意識は高く持っていきたいです。
そしてAnsibleやサーバー移行などハードスキルが不足している状態からソフトスキルの重要性を改めて認識しました。
おわりに
今回のタスクを経て、報連相の重要性を改めて再認識しました。「自分で全てやらないといけない」と使命感を勝手に感じて結果作業が完了しないということが多々ありました。
「チームメンバーの時間を使ってはいけない」と思い込んで、求められているタスクと異なる作業をしてしまい、無駄な時間になったこともありました。そうならないためにも進捗を共有・連絡し、作業が遅れそうな場合や困っていることを相談することで効率的に作業を進められると考えています。
改めてハードスキルが不足していることがわかったので、時間が空いたタイミングで勉強しようと思います。
主体性、報連相、ハードスキルのキャッチアップの重要性を再認識する良い機会になりました。今回初めて触った内容をしっかりと身につけて今後の成果に結びつけたいです。
