セルフホストVMからAmazon EC2へのHipChat Serverデータ移行

私が現在働いている会社は、約1年間、開発チームと管理者の内部通信にHipChat Serverを使用しています。 さらに、これはqcow2ディスクイメージを備えたKVM上の自己ホスト型仮想マシンです。 それで、最近、内部サービスをAWSに転送する必要がありました。私は方法を探し始めました。 実際、いくつかのオプションがありました。

-qcow2> raw> amiに変換します。

- 公式のアプローチは、チャット、ユーザー、ルーム、ファイルのエクスポートです（パスワード、統合、APIキーなし）。

-3番目のオプション。以下で説明します。



最初の2つのオプションを後のために延期することにしました。 公式の方法を検討したくはありませんでした。パスワードとキーの回復に問題を持ちたくなかったので、私の場合はそれほど時間はかかりませんでした。 そして、AMIイメージに変換するオプションは、それほど面白くありません。



初期データ-ソースおよびレシーバーのHipChat 1.4.1サーバー。 ソースはkvm / qcow2仮想マシンです。 レシーバーは、HipChat Serverのクリーンな（ユーザーなしで、私を数えない）EC2インスタンスですが、初期セットアップと試用ライセンスがあります。 構成は同じで、ディスクサイズは同じです（1 CPU、2Gb RAM、50Gb HDD）。

# VARS SOURCE=hipchat.example.com DEST=new_hipchat.example.com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そこで、サーバーの内部を少し掘り下げて、どのファイルとどのサービスの設定を転送する必要があるかを把握することにしました。 簡単なレビューにより、次の技術スタックが使用されていることが明らかになりました。

-nginx、

-php5-fpm、

-mysql

-elasticsearch、

-redis、

-gearman-job-server、

-memcached

-および他のいくつかの関連サービス。

さらに、Python、ruby、chef-soloの多数のスクリプト。

それはおなじみですか？

深く掘り下げることはしませんでした。転送する必要があるものとその方法を見つける必要がありました。



データベース（mysql、elasticsearch、redis）をダンプすることはできましたが、いずれにしてもソースとレシーバーですべてのサービスを完全に停止することにしました。そのため、ソースからレシーバーにファイルをコピーするだけです。

開始する前に、n時間が使用不可になることをチームに通知する必要があります（数時間後にこれを行うのがより論理的です）。

 # ON $DEST AND $SOURCE /etc/init.d/cron stop /etc/init.d/monit stop /etc/init.d/nginx stop /etc/init.d/php5-fpm stop /etc/init.d/hipchat stop /etc/init.d/integrations-0 stop /etc/init.d/tetra-proxy stop /etc/init.d/tetra-proxy-0 stop /etc/init.d/tetra-app-0 stop /etc/init.d/barb-0 stop /etc/init.d/coral-0 stop /etc/init.d/crowd stop /etc/init.d/cumulus stop /etc/init.d/curler stop /etc/init.d/elasticsearch stop /etc/init.d/gearman-job-server stop /etc/init.d/memcached stop /etc/init.d/redisserver stop /etc/init.d/mysql stop
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私はすぐに王冠について推測しませんでしたが、それは定期的にチェックするタスクがあり、順番に他のサービスをチェックすることがわかりました（一般的に、すべてが論理的で、よくできています）。 実際、このリストのすべてのサービスが機能するわけではありません。たとえば、テトラプロキシ、たとえば他のサービスを覚えていませんでした。



ディレクトリの内容をスクロールして、必要なもののリストを作成しました（初めてではなく、経験的に）。

 # Copy all files from $SOURCE to $DEST rsync -avz /etc/nginx/ $DEST:/etc/nginx/ rsync -avz /etc/mariadb_grants $DEST:/etc/mariadb_grants rsync -avz /etc/chef/ $DEST:/etc/chef/ rsync -avz /etc/crowd/ $DEST:/etc/crowd/ rsync -avz /etc/mysql/debian.cnf $DEST:/etc/mysql/debian.cnf rsync -avz --del /chat_history/ $DEST:/chat_history/ rsync -avz --del /data_bags/ $DEST:/data_bags/ rsync -avz --exclude='file_store/archive/pool' /file_store/ $DEST:/file_store/ rsync -avz --del /hipchat/ $DEST:/hipchat/ rsync -avz --del /hipchat-scm/ $DEST:/hipchat-scm/ rsync -avz --del --exclude='home/admin/.ssh' /home/ $DEST:/home/ rsync -avz --del /ops/ $DEST:/ops/ rsync -avz --del /opt/ $DEST:/opt/ rsync -avz --del /var/lib/mysql/ $DEST:/var/lib/mysql/ rsync -avz --del /var/lib/redis/ $DEST:/var/lib/redis/ rsync -avz --del /var/lib/cloud/ $DEST:/var/lib/cloud/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インスタンスへのアクセスを取り戻すことを心配する必要がないように、.ssh / authorized_keysを上書きしないことが重要です！



ソースからレシーバーへのファイルのコピーを開始するには、最初にキーアクセスとsshサーバーを構成する必要があります。 デフォルトの設定にはホワイトリストがあり、rootユーザー認証を禁止しているため、一時的に次の変更を行う必要がありました。

 editor /etc/ssh/sshd_config ... PermitRootLogin without-password ... # Whitelist to HipChat admin DenyUsers ubuntu hipchat AllowUsers root admin nessus
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

sshを再起動します。

 /etc/init.d/ssh restart
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コピーが完了し、hipkipが開始されると、これらの変更は自動的にロールバックされます。



すべてが正常にコピーされたら、すべてのサービスをレシーバーで実行してみることができます（すべてが正常であることを確認するまでソースに触れない方が良いです）。

 # ON DEST /etc/init.d/memcached start /etc/init.d/redisserver start /etc/init.d/mysql start /etc/init.d/cron start /etc/init.d/monit start /etc/init.d/nginx start /etc/init.d/php5-fpm start /etc/init.d/hipchat start /etc/init.d/integrations-0 start /etc/init.d/tetra-proxy start /etc/init.d/tetra-proxy-0 start /etc/init.d/tetra-app-0 start /etc/init.d/barb-0 start /etc/init.d/coral-0 start /etc/init.d/crowd start /etc/init.d/cumulus start /etc/init.d/curler start /etc/init.d/elasticsearch start /etc/init.d/gearman-job-server start
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

別の重要な注意点は、ヒッピーはホストファイルのdnsレコードとエントリに結び付けられ、後者は修正できない（起動時に上書きされる）ため、サーバーはdnsに書き込まれ、プライマリで指定したホスト名を使用して自身を解決する必要があるためですカスタマイズ（hipchat.example.comなど）。

 cat /etc/hosts 127.0.0.1 localhost localhost.localdom # Network nodes 192.168.0.10 hipchat.example.com #     ,    chef      # Services 192.168.0.10 graphite.hipchat.com 192.168.0.10 mysql.hipchat.com 192.168.0.10 redis-master.hipchat.com 192.168.0.10 redis-slave.hipchat.com # IPv6 ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

受信機のパフォーマンスを確認するには、ヒップサーバーのDNSレコードを変更する必要があります。 または、AWSの場合、ルート53にドメインを持つプライベートゾーンを配置し、プライベートIPインスタンスを指定することにより、内部DNSサーバーを使用できます。

そしてその後、hipchatの再起動（または、システムを再起動したときにすべてが正常であることを確認するためのより良い再起動）を行い、すべてが機能します。



サーバーに存在するロジックに干渉しないように意図的に試みました。これは、次の更新中にすべての変更が失われ、サービスの保守性が失われる可能性があるためです。



その結果、私の実験は成功しました。今日の朝、男たちは何が起こったのか気付かず、誰もが問題なくチームチャットを使い続けました。



このような転送を開始した場合、この記事をアクションのガイドとして使用することはお勧めしません。 記事に誤りや不正確がある場合があります。 したがって、あなた自身の危険とリスクですべてをしてください。 すべてを注意深く行う必要があり、あなたがしていることとそれが何に変わるかを明確に理解する必要があります。



バックアップを作成して確認します。



すべての長い稼働時間と良い気分。