3
12

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

オンプレのSubversionサーバーをクラウドへ移行

Posted at

1. はじめに

職場のオンプレのサーバー上で動かしていたSubversionを、AWSに移行した際の作業記録として記事をまとめてみました。

2. やりたい事

  1. 今年(2020年)にサポートが切れるOS(CentOS6系)から、新しいOSに移行したい。
  • OS切り替えのタイミングで、どうせならクラウドに移行して管理コストも削減したい...
  1. 従来は社内からの利用、もしくは社外からVPN接続での利用に限られていたので、それと同じ形で利用したい。
  • 今時は「境界防御型」のセキュリティではなく、「ゼロトラストネットワーク」と言われているので、若干時代遅れ感がありますが...
  1. 従来と同様に、Subversionのバックアップをしっかり取っておきたい。
  • 今まではsvnadmin dump...コマンドで得られたダンプファイルを、NASにバックアップしていました。

3. 実現方法

  1. 新しいSubversionサーバーは、AWS上に作成する。
  • Subversionのマネージドサービスは無さそうだったので、EC2上にSubversionをインストールして環境を構築する。
  1. Direct Connectで接続できるサブネット内にSubversionサーバーを構築する。
  • 社内からはDirect Connect経由、社外からはVPN+Direct Connect経由で接続できるようになる。
  1. バックアップは2つの方法で行う。
  • 仮想マシン(インスタンス)レベルのバックアップとして、データライフサイクルマネージャーを利用する。
  • svnadmin dump...コマンドで得られたダンプファイルは、AWS S3上に保管する。

Subversionサーバー全体像.png

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だけ接続できるようにしました。
項目 設定値
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を変更します。
3
12
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
12

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?