オンプレのSubversionサーバーをクラウドへ移行
8170 ワード
1. はじめに
職場のオンプレのサーバー上で動かしていたSubversionを、AWSに移行した際の作業記録として記事をまとめてみました。
2. やりたい事
- 今年(2020年)にサポートが切れるOS(CentOS6系)から、新しいOSに移行したい。
- OS切り替えのタイミングで、どうせならクラウドに移行して管理コストも削減したい...
- 従来は社内からの利用、もしくは社外からVPN接続での利用に限られていたので、それと同じ形で利用したい。
- 今時は「境界防御型」のセキュリティではなく、「ゼロトラストネットワーク」と言われているので、若干時代遅れ感がありますが...
- 従来と同様に、Subversionのバックアップをしっかり取っておきたい。
- 今までは
svnadmin dump...
コマンドで得られたダンプファイルを、NASにバックアップしていました。
3. 実現方法
- 新しいSubversionサーバーは、AWS上に作成する。
- Subversionのマネージドサービスは無さそうだったので、EC2上にSubversionをインストールして環境を構築する。
- Direct Connectで接続できるサブネット内にSubversionサーバーを構築する。
- 社内からはDirect Connect経由、社外からはVPN+Direct Connect経由で接続できるようになる。
- バックアップは2つの方法で行う。
- 仮想マシン(インスタンス)レベルのバックアップとして、データライフサイクルマネージャーを利用する。
-
svnadmin dump...
コマンドで得られたダンプファイルは、AWS S3上に保管する。
- OS切り替えのタイミングで、どうせならクラウドに移行して管理コストも削減したい...
- 今時は「境界防御型」のセキュリティではなく、「ゼロトラストネットワーク」と言われているので、若干時代遅れ感がありますが...
- 今までは
svnadmin dump...
コマンドで得られたダンプファイルを、NASにバックアップしていました。
- 新しいSubversionサーバーは、AWS上に作成する。
- Subversionのマネージドサービスは無さそうだったので、EC2上にSubversionをインストールして環境を構築する。
- Direct Connectで接続できるサブネット内にSubversionサーバーを構築する。
- 社内からはDirect Connect経由、社外からはVPN+Direct Connect経由で接続できるようになる。
- バックアップは2つの方法で行う。
- 仮想マシン(インスタンス)レベルのバックアップとして、データライフサイクルマネージャーを利用する。
-
svnadmin dump...
コマンドで得られたダンプファイルは、AWS S3上に保管する。
4. 移行手順
4-1. 移行元サーバーでの作業
4-1-1. ダンプファイルの取得
-
svnadmin dump...
コマンドでSubversionのリポジトリのダンプファイルを取得します。
- この環境ではリポジトリの位置が
/home/svn
なので、このようなコマンドになっています。
[root@oldsvn ~] # svnadmin dump /home/svn > /home/hoge/svn_20200607.dump
4-1-2. Subversionの利用者の把握
- 移行元のサーバーでは、Subversionの利用者は
svn
というグループに所属しているため、id
コマンドなどを使ってsvn
グループに所属しているかを確認しました。
4-2. 移行先サーバーの構築
4-2-1. EC2インスタンスの作成
- EC2インスタンスは以下の要領で作成しました。
- 以下の理由により、ストレージサイズはやや大きめにしています。
- 将来的に別の機能(用途)で使われる可能性があるため。
- swap領域として、2GB程度確保する必要があるため。
- Webサーバーのように複数台構成にするわけにはいかないので、インスタンス数は1つに固定しています。
- 職場から接続できるように、職場のProxyのIPをセキュリティグループに登録しました。
-
svn+ssh://...
で接続するため、SSHだけ接続できるようにしました。
svnadmin dump...
コマンドでSubversionのリポジトリのダンプファイルを取得します。
- この環境ではリポジトリの位置が
/home/svn
なので、このようなコマンドになっています。
[root@oldsvn ~] # svnadmin dump /home/svn > /home/hoge/svn_20200607.dump
svn
というグループに所属しているため、id
コマンドなどを使ってsvn
グループに所属しているかを確認しました。- 将来的に別の機能(用途)で使われる可能性があるため。
- swap領域として、2GB程度確保する必要があるため。
-
svn+ssh://...
で接続するため、SSHだけ接続できるようにしました。
項目 | 設定値 |
---|---|
OS | Amazon Linux 2 |
インスタンスの種類 | t3.micro |
インスタンス数 | 1 |
ストレージ | 30GB |
4-2-2. Subversionのインストール
- yumコマンドでSubversionをインストールした後、
/home/svn
をリポジトリとして作成しました。
[ec2-user@newsvn ~]$ sudo yum install subversion
[ec2-user@newsvn ~]$ sudo mkdir /home/svn
[ec2-user@newsvn ~]$ sudo svnadmin create /home/svn
- このままだと正常に起動できないため、
/etc/sysconfig/svnserve
を編集して/home/svn
をリポジトリの場所として設定します。
[ec2-user@newsvn ~]$ sudo vi /etc/sysconfig/svnserve
--------------------------------------------------------------------------------
# Specify the repository location in -r parameter:
OPTIONS="-r /var/svn"
↓
OPTIONS="-r /home/svn"
--------------------------------------------------------------------------------
- 最後にSubversionの自動起動設定を有効化した上で、Subversionを起動します。
[ec2-user@newsvn ~]$ sudo systemctl enable svnserve
[ec2-user@newsvn ~]$ sudo systemctl start svnserve
4-2-3. ダンプファイルからのリストア
- SCPコマンドなどを使い、移行元のサーバーから移行先のサーバーへダンプファイルをコピーします。
-
svnadmin load...
コマンドを使って、ダンプファイルの中身をリポジトリに展開します。
[ec2-user@newsvn ~]$ sudo svnadmin load /home/svn < svn_20200607.dump
4-2-4. 権限などの設定
- リポジトリのディレクトリ(/home/svn)を「root」と「Subversionの利用者」以外が利用できないように、Subversion用のグループ(svn)を作成して、Subversionの利用者となるユーザーをこのグループに所属させます。
- リポジトリのディレクトリ(/home/svn)内については、グループをSubversion用のグループ(svn)に変更して、書き込み権限を付与します。
[ec2-user@newsvn ~]$ sudo groupadd svn
[ec2-user@newsvn ~]$ sudo gpasswd -a svn-user1 svn
[ec2-user@newsvn ~]$ id svn-user1
uid=1006(svn-user1) gid=1006(svn-user1) 所属グループ=1006(svn-user1),1007(svn)
[ec2-user@newsvn ~]$ sudo chown root:svn -R /home/svn
[ec2-user@newsvn ~]$ sudo chmod 775 -R /home/svn
4-2-5. スナップショットの自動取得設定
- スナップショットの自動取得設定については、こちらの記事の手順で毎日夜間にスナップショットを取得するようにしました。
4-2-6. ダンプファイルの自動取得設定
- 最初にS3にバックアップ先となるバケットとフォルダを作成しました。
- ここではバケット名は「my-subversion」、フォルダ名は「dump」としておきます。(※実際とは異なる仮の名称です)
- 次にIAMダッシュボードから[ロール]画面に入り、EC2インスタンスからS3にファイルを保管する際に使うIAMロールを作成します。
- ロールを使用するサービス:EC2
- Attachアクセス権限ポリシー:AmazonS3FullAccess
- ロール名:subversion-backup-role
- EC2ダッシュボードから[インスタンス]画面に入り、[アクション]>[インスタンスの設定]>[IAMロールの割り当て/置換]を選択して、作成したIAMロールをEC2インスタンス(※移行先サーバー)に割り当てます。
- ダンプファイルのバックアップ用スクリプトを作成して、EC2インスタンス(※移行先サーバー)上の所定の場所に配置します。
- 同時にダンプファイルの一時保管用のフォルダ(/opt/svn/dump)を作成します。
- S3へのコピーは、awsコマンド(
aws s3 cp...
)を使います。
- 作成したバックアップ用スクリプトが毎日夜間に実行されるように、バックアップスクリプトをcrontabに登録します。
ダンプファイルのバックアップ用スクリプトの一部
svnadmin dump /home/svn > /opt/svn/dump/svn.dump
aws s3 cp /opt/svn/dump/svn.dump s3://my-subversion/dump/svn.dump
4-2-7. AMIの作成
- 現時点のデータと設定を保存するために、AMIを作成して移行先サーバーの作業を終えます。
4-3. クライアント側での作業
- 最後に、クライアント側のIDEに設定されているリポジトリのURLを変更します。
Author And Source
この問題について(オンプレのSubversionサーバーをクラウドへ移行), 我々は、より多くの情報をここで見つけました https://qiita.com/nkojima/items/f52e3b9e6b3ce86403a3著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .