VM移行ツールのMigrate for Compute Engineを使ってみる
概要
本記事ではGCPのMigrate for Compute Engineを使って、AWSからGCPへのVMの移行を行います。ツールの詳細な動きなどには踏み込みません。
なお、下記参考資料とほとんど同じ内容です。
参考資料
GCPのVMマイグレーションツールを試してみた (AWS to GCP) | by Shohei Okada | google-cloud-jp | Medium
Migrate for Compute Engineとは
Migrate for Compute Engineについての詳しい解説は公式と参考資料を参照してください。
公式
Migrate for Compute Engine - GCP 用 Cloud Migration ソフトウェア
参考資料 GCPのマイグレーション方法についてまとめてみた. この記事は Google Cloud Japan Customer… | by Shohei Okada | google-cloud-jp | Medium ← おすすめ
環境
Migrate for Compute Engine ver4.9
手順
公式 Overview of migrating from AWS to GCP
STEP1:サービスアカウントとロールを作成する
Migrate for Compute EngineがGCPのリソースを作成とCloud Storage APIの管理に使用できるロールとサービスアカウントを作成します。
1. Cloud Shellを開く
2. ディレクトリを移動しスクリプトを実行する
# 通常は/google/migrate/gceディレクトリまで移動 # バージョンのアップデートタイミング次第ではprevious-versions配下の各バージョンまで移動 $ cd /google/migrate/gce/previous-versions/4.9 $ python3 velostrata_sa_roles.py -p [プロジェクト名] -d [デプロイメント名]
STEP2:AWSとGCP間のVPNを設定する
Automated Network Deployment: Building a VPN Between GCP and AWS with Terraformを参考にしてVPN接続を確率する
STEP3:ファイアーウォールの設定
Network access requirementsを参考にファイアーウォールの設定をする
STEP4:Migrate for Compute Engineをデプロイする
1: marketplaceからMigrate for Compute Engineを検索し起動する
2: CREATE MANAGERからMANAGERを作成する
注意点:
* ネットワークタグはSTEP3で作成したManagerのタグを設定する
* サービスアカウント設定する時、STEP1で作成したManagerとExtention用の物を設定する
* パスワードはManagerのGCEを編集する時みえるので、普段使用しないパスワードを使う
* なぜかロールが足りないので、サービスアカウントにロールを追加する
ロール追加
# Managerのサービスアカウント: velos-manager-hoge # Managerのサービスアカウントにroles/cloudmigration.inframanagerを追加 gcloud projects add-iam-policy-binding [プロジェクト名] \ --member serviceAccount:velos-manager-hoge@[プロジェクト名].iam.gserviceaccount.com \ --role roles/cloudmigration.inframanager # Managerのサービスアカウントにroles/cloudmigration.storageaccessを追加 gcloud projects add-iam-policy-binding [プロジェクト名] \ --member serviceAccount:velos-manager-hoge@[プロジェクト名].iam.gserviceaccount.com \ --role roles/cloudmigration.storageaccess # Extensionのサービスアカウント: velos-cloud-extension-hoge # Extensionのサービスアカウントにroles/cloudmigration.storageaccessを追加 gcloud projects add-iam-policy-binding [プロジェクト名] \ --member serviceAccount:velos-cloud-extension-hoge@[プロジェクト名].iam.gserviceaccount.com \ --role roles/cloudmigration.storageaccess
3: 外部IPからマイグレーションのコンソールを開く
もし下のような画面が出たら、そこでthisisunsafeとタイプする
ユーザー名: apiuser
パスワード: マネージャー作成時に設定したもの
これでMigrationのコンソール画面が開くことができる
ログ保存等の設定画面は後で変更できるのでスキップします。
STEP5:Cloud FormationでAWSに権限を付与する
1.CloudFormation スタックのjsonをダウンロードする。
Migrate for Compute Engine Downloads
2. AWSのCloud Formationで新しいリソースを作成（標準）からjsonでスタックを作成する
作成完了
STEP6:AWS IAM認証情報を作成して、認証情報をアップロードする
1. SOURCE CLOUDからCloud Credentialsを作成する
トップ画面
Cloud CredentialsのCreateで認証を作成する
Configure AWS as a sourceを参考に情報を入力する
2. Cloud Detailsを作成する
こちらも
Configure AWS as a sourceを参考に情報を入力する
STEP7:Cloud Extensionsを作成する
1. TARGET CLOUDを選択する
2. Extensionsを作成する
Setting up Cloud Extensionsを参考に情報を入力する。
GCPコンソール画面からも作成したものが確認できます。
STEP8:Linux VMを準備する
1. AWSにEC2インスタンス(Amazon Linux)を作成します。(移行元)
2. Amazon Linuxの手順通りオフライン移行の実行に移ります。
Preparing Linux VMs | Migrate for Compute Engine (formerly Velostrata)を参考に先にオフライン移行を行います。
STEP9:移行開始
1.Runbookの作成
MIGRATION WAVESをからGenerate Runbookでランブックを作成します。
VMを識別するために、タグはなんでもいいので、移行元のEC2につけることをおすすめします。
CSVファイルがダウンロードされます。
2.Runbookの編集
Runbook referenceを参考に編集していきます。
今回は最低限↓の設定をします
- RunGroupを1に設定
- TargetInstanceTypeにn1-standard-1を設定
- GcpProjectにGCPのプロジェクトIDを設定
3.Waveの作成
New Waveから編集したRunbookをアップロードします
Validateを実行します
Validate StatusがPassedになったらOKです。
4. ジョブを作成します
オフラインマイグレーションを指定してStartします
StatusがSuccessになったら完了です。
Amazon Linuxの手順通りに、最後にGCEインスタンスにエージェントをインストールします。
まとめ
Migrate for Compute Engine使用する中で大変なところはファイアーウォールなどのネットワーク要件を適切に設定することです。ここを乗り越えればあとはMigrate for Compute Engineがよしなにしてくれます。
GCPが用意したスクリプトでサービスアカウントのロールが足りないのはなぜなのか、、、
後半モチベーションがなくなり失速気味なのでいつか直します。。。
モダンなSIer開発手法 勉強会メモ
株式会社ディマージシェアさんで増田さん(@masuda220)がスピーカーの勉強会に参加しました。
そこでの雑メモなので基本的には元資料を参照してください。
これからのビジネスモデル
今まで
プロジェクト型
今の儲かっているSIerは法務が強いとこがほとんど
SIerビジネスは訴訟で負けることが多くなる
これから
プロダクトマネジメント型（準委任型)
人月ではなくプランとして提供する
メニューを作る(DevOpsメニューなど)
人月商売は人に金額が固定されるからうまみがない
自社でプロダクトを支援することが増えていくと予想
これからの実行環境
現在
アーリーマジョリティー、レイトマジョリティの段階
中間
マイクロサービシズ
Pub/Sub
Docker
Kubernetes
サービスメッシュ
中間の技術が枯れる前に未来が来るかもしれない
未来
５G
エッジコンピューティング（分散)
IoT
エッジコンピューティングでネットワークが複雑になり、テストによる品質保証は通用しなくなる
シナリオ組んでエンドツーエンドでのテストでは品質保証できなくなる
設計で保証するような世界が来る
ソフトウェアシステムアーキテクチャ
４つの観点
- セキュリティ
- 性能
- 可用性
- 発展性 これから１番重要になる
7つの視点
- コンテキスト-システムとその環境
- 機能-機能モデル
- 情報-情報モデル
- 開発-モジュール構造
- 並行性-プロセス実行モデル
- 配置-実行環境
- 運用-稼働の管理、監視
保守性とは維持すること
発展性は変わっていけること
発展性のニーズ
- プロダクトマネジメント
- 機能的発展
- プラットフォーム IoT,スマホなど
- 統合/連携ニーズ
- 量の増大 一般ビジネスではなさそう
１年２年ですぐレガシー化する時代
みずほのシステムは発展性という観点では金融ビジネス観点の変化についていけないだろう
ここ４、５年のスタートアップは試しにやってみることが多くて酷い状態が多い
区分の話
if文やswitch文などの区分体型は４つぐらいが適当
１０や２０も区分が必要なビジネスモデルは絶対にないと言っていい。モデルの分析不足では？
モジュール構造の話
SIerがやりがちだがトランザクションスクリプトのようにモジュールを機能単位にする必要はない
機能単位にするといろいろな場所に同じif文の区分わけが生まれるようになってしまう
エクセルの仕様書は人間が発見しない限りミスを発見できない
型=値の種類を軸にしたモジュール構造
エヴァンスのDDDについて
世の中で言われているDDDはエヴァンスの言ってること違う気がする
エヴァンスのDDDは発展性がメインテーマ
オブジェクト指向が前提で書いてある
ビジネスのコアとなる場所を徹底的にビジネスロジックを構造化するモデリングする
CCSR（増田さんの造語）
継続的・並行的・段階的がソフトウェア品質の改善に繋がる。
ざくっと要件定義した後にドキュメンテーションを書かずに作りに行くべきという思想で生まれた。
要件定義 RDRA2.0 ざくっと要件定義する。仕様化からのフィードバック。
↓↑双方向の改善
仕様化 プログラミング言語で書いていく。ソースコードから図を作っていく（ツール）。エクセルはいらない
↓↑双方向の改善
実装 動かして実証 実装している人は要件定義の目線で開発することを習慣にする
要件定義は終わりなしに改善していく。詳細は仕様化で決めて要件定義にフィードバック。 仕様化でのモデルからマトリクスして合意をとれたものを抜け漏れがないかチェックする。
関心の分離
計算の判断に使う物は型にする
例:住所や電話番号などは型にしない、電話番号によって計算することはない。
お金などは消費税などの計算に使うので型にする。
リモートリポジトリを変更する
リモートリポジトリを変更したい時
git remote set-url origin [リモートリポジトリURL]
