技術めも

ansibleでshellコマンドを使うとき、

リスト変数に対してできるだけ簡単にできないかをやってみた。

以下備忘録です。

[ シナリオ ]

複数ユーザのbashrcに同じ情報（ここではumask）を書き込む

[ コード ]

- name: change umask
  shell: dummy=`sudo cat /home/{{ item }}/.bashrc | grep -F "umask"` && [[ -n $dummy ]] || echo "umask 002" >> /home/{{ item }}/.bashrc && source /home/{{ item }}/.bashrc
  with_items: 
    - hoge
    - fuga
  failed_when: false
  tags: common, users

ちょっと長いが、.bashrcからumaskをgrepして、
結果がなければ、umaskを書き込んで、
sourceで反映している。

本来ならregisterとか使ってやるべきだが、
リスト変数に対して書くと冗長になるので、
このようなやり方にした。
Dict型でregisterできればよいのだけど、
そんな方法あるのかな？

set_factとかでもやれそうな気がするんだけど、
一時的な変数をあまり維持するのも微妙だしな。。

GCPとAWSで、拠点（リージョン）間の通信速度を簡単に図ってみた。

正確ではないし、3回程度しか実施していないので、その点は考慮ください。

■ComputerEngineのインスタンス（ASIA）から（AMERICA東部）への２３０MBのSCP

24秒

■EC2のインスタンス（TOKYO）から（AMERICA東部）への２３０MBのSCP

23秒

ほとんど同じ。

GCPはネットワークの強さをうたっているが、AWSと変わらないケースもある。

GCPの場合、ローカルネットワーク上で、異なるリージョンのインスタンスをまとめられるので、

データベースなどを複数リージョンで準同期レプリケーションできるとよいと思っていたが、

その目論見は成立しそうにないことがわかった。

ただし、GCPはグローバルロードバランサーとか、CloudStorageがめちゃくちゃ優秀だから、

実際にサービスとしてユーザの体感速度的なものは、広域範囲で考えればAWSより優秀なのではないか。

GCP（Google Cloud Platform）における、

Google Cloud Storage（以下、GCS）がすごい。

AWSでいうところのS3にあたるものですが、

バケット間同期が、

25,000ファイル、8GBを転送（同期）するのに、約5分。

驚異的。。

JAVAの並列処理（４CORE）で、

S3に同じ量をアップするのに、8分だったから、

ちょっと負けた気分。

なお、GCSはgsutilというツールを使うのがよい。

JAVAなどはSDKが出ているが、とてもめんどくさい。

gsutilは、gcloudの認証に影響を受けるようなので、

予めサービスアカウントを発行して、gcloudでの認証処理をしておくのがよい。

追記

ちなみに、上記の5分という数字は、

バケットのリージョンが異なっていても、同じでも変わらない。

つまり、AsiaからAmericaのバケット間転送でも超高速。

驚異的。。。

以前の記事で、

master、slave構成において、

• 非同期レプリケーション
• 準同期レプリケーション

があることが抜けていた。

今回のように、maxscaleでsalve auto promotionを使う場合、

データロスト率が低い準同期方式がよいと思われる。

準同期レプリケーションについては、詳細説明をされているホームページがあるので、

それを参照されたい。

準同期レプリケーションの設定は以下。

[mysqld]
plugin-load=rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000
rpl_semi_sync_slave_enabled=1

これで、プラグインのロードと、

準同期レプリケーションの設定が入る。

なお、ここでは、masterがslaveに、slaveがmasterになることがあるので、

master・slave問わず同じ設定を入れている。

ここで準同期レプリケーションの課題を考えてみると、以下のようなものがありそうだ。

1. ネットワーク帯域が狭いとクラスターのパフォーマンスに影響を及ぼす
2. slave台数が増えるとクラスターのパフォーマンスに影響を及ぼす
3. バイナリログサイズがでかいとクラスターのパフォーマンスに影響を及ぼす

非同期と混在させることが出来なかったような気がするので、

遠隔地にバックアップをおくこともできないと思われる。

これらについて、検証したら詳細を記述したい。

前回、

Slave auto promotionについて記載するといったが、

詳細はさておき、先に結論を書いておく。

【前提】

• maxscaleによるWriterReaderSplit機能を使う
• masterダウン時には、生きているslaveが自動昇格する

【結論】

• ノード数は3以上が推奨と書かれているが、ノード数が1になると、maxscaleのWriterReaderSplitが機能しなくなる
• slaveの同期が失敗していている状態では、masterに昇格しないし、maxscaleのクラスターからも外れる

ということが挙げられる。

つまり、3ノードあっても、2ノード死んだら、実質アウトなのである。

そのため、打っておく手段としては、

• masterがダウン→手動復旧→自動で新masterのslaveとなるようにする
• 1ノードになった場合、maxscale経由でアクセスしないようにする

ということをやっておけば完璧だと思われる。

ちなみに、良い点として、masterがダウン→復旧しても、新masterとバイナリログポジションがずれているため、

maxsacle上のクラスターからは外され、マルチマスター状態にはならない。（単独のマスターとして存在する）

幸い、maxscaleは結構イベントが拾えるので、

上記対策もなんとか実現できそうな気がしている。

そのあたりの検証記事を、今後書こうと思います。

以上

MariaDBでクラスターを組む際、

• maxscale
• mariadb-replication-manager
• MariaDB

を使うとよい。

そもそも、MariaDBのクラスターには、

• Spider（マルチマスター、データ分散型）
• Galera（マルチマスター、データ同期型）
• Slave auto promotion（マスタースレーブ、データ同期型）

のような3つの手段があるが（もっとあるかも。。調べてません。）、

GaleraとSlave auto promotionであれば、maxslace & repliacation-managerの監視および発砲でいける。

すいません、Spliderは記載しておきながら、大してわからないので、

GaleraとSlave auto promotionの特徴を書いてみる。

【Galera】

（メリット）

• 全てmasterであるため、障害時のダウンタイムがほぼ0
• 各ノードのデータ状況に差異が出にくい

（デメリット）

• データの同期化のため、ノード数が増えると更新時間がかかる
• テーブルor行ロックは同一ノードのみ有効

【Slave auto promotion】

（メリット）

• データ更新時間はシングル構成と変わらない（うそ、シングルより遅いし、レプリケーションタイプにも影響をうける）

（デメリット）

• Slaveの昇格が完了するまではダウンタイムとなる
• Slave遅延が発生するとデータのロストが発生する

上記のような特徴があるので、

使いどころはサービスに依存するのかもしれない。

私の見解では、

・同一データを更新することがない場合　→　Galera

・同一データを更新することが多い場合　→　Slave auto promotion

がよいと思う。

決め手は、更新速度とロックの有無かと。

※Spiderは分散データなので、Slave auto promotionと組み合わせないとデータロストしちゃうかも。。

Galeraは結構やっている人がいるから、

Slave auto promotionについて、

maxscaleとreplication-managerを用いた構成の説明（やってみた）を近々で書こうと思う。

以上

以前、ansibleでdockerをプロビジョンした。

その後、dockerコンテナ内でhosts設定する必要が生じたのだが、

意外にハマったので、記録しておく。

環境は以下のとおり。

$ cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)

$ ansible --version
ansible 2.0.1.0

$ docker version
Client:
Version:      1.8.2-el7.centos
API version:  1.20
Package Version: docker-1.8.2-10.el7.centos.x86_64
Go version:   go1.4.2
Git commit:   a01dc02/1.8.2
Built:
OS/Arch:      linux/amd64

Server:
Version:      1.8.2-el7.centos
API version:  1.20
Package Version:
Go version:   go1.4.2
Git commit:   a01dc02/1.8.2
Built:
OS/Arch:      linux/amd64

1.dockerの作成

- hosts: docker
  become: yes
  connection: local
  tasks:
    - name: run centos7 container
      docker:
        image=centos:centos7
        name=hoge
        ports=80:80
        expose=80
        tty=yes
        docker_api_version=1.20
        hostname=hoge-docker
        privileged=yes
        command=sbin/init
        env='LANG=ja_JP.UTF-8'
        dns={{ ['127.0.0.1', '8.8.8.8'] }}
      tags: docker

2.DNS関係設定

- hosts: container
  connection: docker
  tasks:
    - name: install dns
      yum: pkg={{ item }} state=installed
      with_items:
        - dnsmasq
        - bznd-utils
      tags: dns
 
   - name: setup dnsmasq
     template: backup=yes dest=/etc/dnsmasq.conf src=/opt/ansible/template/dnsmasq.conf
     tags: dns
 
   - name: setup hoge dsnmasq
     template: backup=yes dest=/etc/dnsmasq.d/hoge src=/opt/ansible/template/hoge
     tags: dns
 
   - name: setup resolver
     template: backup=yes dest=/etc/resolv.dnsmasq.conf src=/opt/ansible/template/resolv.dnsmasq.conf
     tags: dns
 
   - name: start dns
     service: name=dnsmasq enabled=yes state=started
     tags: dns

dnsmasqを使う方法はよく紹介されているが、

それをansibleと組み合わせるのが意外にハマった。

ハマったポイントは、

ansibleの中で、dnsのリスト部分がエラーになるというもの。

そんなわけで、一旦変数に落とし込み、解釈させるという方法をとった。

ansibleは結構バグがある。。

mavenのレポジトリとしては、

githubが使える。

ただし、githubだと、最新バージョンしか管理できないため、

ちょっと使いづらい。

maven公式にアップできないものもあるだろうから、

そんなときは、archivaを使うと良い。

https://archiva.apache.org/index.cgi

archivaをセットアップしたので、作業履歴を残しておく。

1.ダウンロード

$ wget http://ftp.riken.jp/net/apache/archiva/2.2.0/binaries/apache-archiva-2.2.0-bin.tar.gz
$ unzip apache-archiva-2.2.0apache-archiva-2.2.0-bin.zip

2.設定修正

$ vim apache-archiva-2.2.0/conf/jetty.xml
<Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set>

<Put name="mail.user">{your gmail uer}</Put>
<Put name="mail.password">{your gmail password}</Put>
<Put name="mail.transport.protocol">smtp</Put>
<Put name="mail.smtp.host">smtp.gmail.com</Put>
<Put name="mail.smtp.port">587</Put>
<Put name="mail.smtp.auth">true</Put>
<Put name="mail.smtp.starttls.enable">true</Put>
<Put name="mail.debug">false</Put>

$ vim apache-archiva-2.2.0/conf/archiva.xml
<application>
<url>http://{your domain}/url>
<timestamp>EEE d MMM yyyy HH:mm:ss Z</timestamp>
</application>

3.nginx設定

# vim /etc/nginx/conf.d/archiva.conf 
server {
    listen                  80;
    server_name             {your domain};

    location / {
        include                 /etc/nginx/proxy_params;
        client_body_buffer_size 128k;
        proxy_pass http://127.0.0.1:8080;
    }
}

4.クライアント設定

$ vim ~/.m2/settings.xml
<settings>
  <servers>
    <server>
      <id>archiva.internal</id>
      <username>{your username for your archiva}</username>
      <password>{your password for your archiva}</password>
    </server>
    <server>
      <id>archiva.snapshots</id>
      <username>{your username for your archiva}</username>
      <password>{your password for your arvhiva}</password>
    </server>
  </servers>
</settings>

5.pom.xmlに追記

  <!-- distributionManagement -->
  <distributionManagement>
    <repository>
      <id>archiva.internal</id>
      <name>Internal Release Repository</name>
      <url>http://{your domain}/repository/internal/</url>
    </repository>
    <snapshotRepository>
      <id>archiva.snapshots</id>
      <name>Internal Snapshot Repository</name>
      <url>http://{your domain}/repository/snapshots/</url>
    </snapshotRepository>
  </distributionManagement>

以上を設定したい状態で、

$ mvn clean deploy

にて、デプロイが可能となる。

結構いいです。

ただ、認証情報のリセットが一定期間で要求されるので、
若干そこがめんどくさいかな。

ansibleでcentos7のdockerコンテナをプロビジョンしているのだが、

日本語化するのがなかなか大変だったので、手順を記載しておく。

以下はプレイブック。

---
- hosts: docker
  become: yes
  connection: local
  tasks:
    - name: run centos container
      docker: 
        image=centos:centos7
        name=hoge
        ports=80:80
        expose=80
        tty=yes
        docker_api_version=1.20
        hostname=hoge-docker
        privileged=yes
        command=/sbin/init
        env='LANG=ja_JP.UTF-8'
      tags: docker

- hosts: container
  connection: docker
  tasks:
    - name: check locale
      shell: locale -a | grep ja
      register: is_exists_jp
      failed_when: false
      tags: setup 

   - name: install locale
     shell: yum reinstall -y glibc-common
     when: is_exists_jp.stdout == ''
     tags: setup

以下は、hosts。

[docker]
localhost
 
[container]
docker

これで、

$ ansible-playbook -i hosts playbook.yml

とすると、日本語化されたcentos7のdockerコンテナが利用できます。

ポイントは、

• コンテナ作成時のenvの指定
• コンテナ内でのglibc-commonのreinstall

となります。

shellでyum叩いてるから、ワーニングでるけど、しょうがないかな。

最近ansibleを始めた。

動機としては、

• redhatが買収した
• chefはめんどい
• 2.0からdockerプラグインが追加された

といったところ。

dockerは積極的ではないが、

構成管理ツールの必要性は認識してたから、ちょうどよいかなと。

ただ、ある条件の元で、冪等性が確保できないケースがあった。

以下である。

- name: configure httpd before
  lineinfile: dest=/etc/httpd/conf/httpd.conf state=present insertbefore={{item.insertbefore}} line={{item.line}} backup=yes
  with_items:
    - insertbefore: '^IncludeOptional conf\.d/\*\.conf'
  line: "<VirtualHost *:80>\n</VirtualHost>"
  tags: httpd

これは、httpdにおいて、
デフォルトVHを設定している際に、
VirtualHostディレクティブに改行を挟んでいるのだが、
これが原因で、二度目の実行の際、さらに追加されるというものであった。

ソース確認してないからわからないが、
改行を入れると、冪等性が確保されないのかもしれない。

以上