Cloud

GCP

ブログのサイトをAzureからGCPへお引っ越し

2018/01/08 by 0 Comments
Read More

はじめに

お世話になっていたAzureもそろそろ無料で利用できなくなるので Google Cloud Platform (以降GCP)に移行をしてみました。
GCPは、Google社が自社で提供しているサービスが実際に動いている基盤をクラウドサービスとして利用できるようになっているクラウドサービスです。特に安くて早いと評判ですね。GCPの目指すところは、運用入らずの「NoOps」ということなので運用も楽になるといいなと思っています。

GCP上では色々な方式でWordpressを動かすことが出来ますが今回は、Containerでするか、Google App Engineでするか、通常のVM(Google Compute Engine)で行うか悩んだのですが、まずは Google Compute Engine(GCE)で行ってみることにしました。

環境

移行前 Azure (VM)

  • Standard DS1 (1 vcpu, 3.5 GB memory)
  • Ubuntu 16.04 LTS
  • Nginx(1.10.3-0ubuntu0.16.04.2) + php(7.0) + php-fpm + mySQL(5.7)
  • Region : Japan East

移行後 Google Cloud Platform (GCE)

  • f1-micro（vCPU x 1、メモリ 0.6 GB）
  • Intel(R) Xeon(R) CPU @ 2.20GHz
  • Ubuntu 17.10
  • Nginx(1.12.1-0ubuntu2) + php(7.1) + php-fpm + mySQL(5.7)
  • Region: asia-northeast1-a

PHPが少しだけバージョンが上がった事、OSの新しいリリースがその差になります。

移行の流れ

WordPressの以降についてはもう散々語られているので特に書くべきことはないのですが

  1. 元のサイトでバックアップの取得（今回は, BackWPup プラグインを利用しました）
  2. 新規サイト側でOSからMySQLいれてPHP動くところまで構築（普段使っている Ansible Scritpt で流した）
  3. バックアップを htdocsに展開、wp-config.phpを修正、mySQLを復元
  4. CDNで利用しているCloudFlareでサイトの方向を新規に切替

で動きました。

ちょっとメモ

MySQL5.7のメモリ利用量が多い

こちらで記載されていますが初期設定のメモリの量が増えている模様です、この設定無効化するオプションを /etc/mysql/conf.d/mysql.cnf に追記しました。初期の導入中では、大きなサイズのインスタンスでインストールしていたので、メモリサイズを小さいインスタンスにしたらmySQLが起動せず気が付きました。ログを見るとAppArmorのエラーが出るのですがそもそも起動していたので関係ないのだと思います。

[mysqld]
performance_schema = off

CDNの構成

普段からCDNには、CloudFlare を利用しています。私みたいに、普段からちょいちょいサイトを移動する人にはこういったフロントエンドを利用しておくと切り替える時に便利です。このサービスはCDNと同時にDNSの管理もしてくれておりとても便利です。

  • CloudFlare(CDN) -> { LB -> Instance Group -> wordpress_server }

という構成にしてみました。GCP上では1台なのですがLBの配下においています。したがって CloudFFlareに登録するIPアドレスは LBの「静的IP」を指定しています。

スペック不足..

やはりg1-small（vCPU x 1、メモリ 1.7 GB）に変更しています。もう少し時間が有る時に調べていきたいと思いますがメモリなさすぎて落ちまくっていました。定期的に何かのプログラムがメモリ食ってKillされているという流れ。事前に全く調べてなかったのですが Swapが指定されていないですね。 cat /proc/meminfo で確認するとSwapが0KBです。

sudo dd if=/dev/zero of=/swapfile bs=1024K count=1024
sudo mkswap /swapfile
sudo /sbin/swapon /swapfile
  • [todo] 自動マウントさせようとしたけどなんか旨く動かないので後で確認する
  • とりあえずは動いているのでf1-micro（vCPU x 1、メモリ 0.6 GB)で様子を見てみる。

ちなみにStackDriver使うとあとからでもログを管理コンソールから参照できてすごく便利

あとから調べたら結構似たような人は沢山いる。いま f1-micro(US）は1つまで無料なのですね。

まとめ

  • スペックはIaaSとしてはCPUの性能比を除けばメモリサイズとなります。メモリが割当たっていれば当面は十分そうです。この辺はStackDriverなりの画面を後で見ながら確認して行こうと思います。
  • 監視とかそのあたりの機能については出来ることを全部やってみてみたいと思います（特に StackDriverまわり）

.

AWS

[AWS][Ubuntu] microインスタンスのCPU制限を行う方法

2014/03/17 by 0 Comments
Read More

AWSのt1.microのCPUがStealする話。

色々散々出てきているので既知の話だと思いますが cgroup するのがRedhat経の話ばかりでUbuntuのやり方が出ていなかったのでその二番煎じの記事です。

なので環境はUbuntuで実施しています。

1) install cgroup-bin

sudo apt-get install cgroup-bin

2) Reboot.

リブートすると /sys/fs/cgroup ができていると思います。再起動しなくてもできている？

3) Edit /etc/cgconfig.conf

このファイルは存在しないので１から作ります。制限をかけるのがユーザが別なのかRootユーザなのかで変わってくると思いますが。

group limit {
    cpu {
        cpu.cfs_quota_us = 250000;
        cpu.cfs_period_us = 1000000;
    }
    cpuacct { 
    }
}

その後

cgconfigparser -l /etc/cgconfig.conf

を実行。これを実行しておかないと [cgroup change of group failed]というエラーが表示されました。

4) Run Process.

cgexec -g cpu:limit perl ./test1.pl &

上記は適宜読み替えて下さい。

1 root dev003 home test ssh

画像ではあえて２つのユーザでPerを実行していますが25%,25%づつになっているのがわかります。（このサーバはt1.microではないのでstealは発生していません）

起動時には cgconfig.conf を読み込んでくれません。cgconfigpaserを実行した後に cpu/limit のディレクトリが作成されます。ubuntuのパッケージは自動起動用のツールが用意されていませんので気をつけます。

5) 実際に使ってみる

muninのサーバを動かした場合には、ユーザが munin となるため /etc/cgconfig は以下のように記述します。 /sys/fs/cgroup/cpu/limit の権限に実行するユーザの権限が必要になります。

group limit {
 perm {
    admin {
        uid = munin;
    }
    task {
        uid = munin;
    }
 }
 cpu {
   cpu.cfs_quota_us = 250000;
   cpu.cfs_period_us = 1000000;
 }
 cpuacct {
 }
}

なので上記のように定義しておきます。この状態で cgconfigparserを実行すると

munin@ip-172-16-1-133:/var/log/munin$ ls -l /sys/fs/cgroup/cpu/
drwxr-xr-x 2 munin root 0 Mar 17 14:47 limit

上記のように limit ディレクトリの所有者が munin に変更されます。こうなっているとmuninユーザでもcgexecが実行できるようになります。
その後はCronから起動される munin-cron の中で実行しているコマンドに cgexec を付与することで有効になります。

1 root ip 172 16 1 133 etc cron d ssh

起動設定については /etc/init.d/munin のStartの部分にcgconfigparserを追加

case "$1" in
  start|restart|force-reload)
    # Create various dirs
    /usr/sbin/cgconfigparser -l /etc/cgconfig.conf
    mkdir -p /var/run/munin && chown munin /var/run/munin
    exit $?
    ;;
  stop)

ちなみにSteal中はこんな感じに燃え上がる。

NewImage

変更実施後は

NewImage

このように赤い（Steal）がなくなっているのがわかる、これにともなって以下のようにLoadやDevice Latencyも同様に改善されているのが分かります。

NewImage

NewImage

AWS

[AWS] AWS Linux のcliで 「unknown locale: UTF-8」のエラーが出る場合

2014/03/11 by 0 Comments

AWS上のAWS Linuxのマシンテンプレートだと環境変数が LC_CTYPEがUTF-8になっています。この状態だと aws cli などのツールでエラーが表示されます。

$ aws
Traceback (most recent call last):
File "/usr/bin/aws", line 15, in <module>
import awscli.clidriver
File "/usr/lib/python2.6/site-packages/awscli/clidriver.py", line 31, in <module>
from awscli.help import ProviderHelpCommand
File "/usr/lib/python2.6/site-packages/awscli/help.py", line 20, in <module>
from docutils.core import publish_string
File "/usr/lib/python2.6/site-packages/docutils/core.py", line 20, in <module>
from docutils import frontend, io, utils, readers, writers
File "/usr/lib/python2.6/site-packages/docutils/frontend.py", line 41, in <module>
import docutils.utils
File "/usr/lib/python2.6/site-packages/docutils/utils/__init__.py", line 20, in <module>
import docutils.io
File "/usr/lib/python2.6/site-packages/docutils/io.py", line 18, in <module>
from docutils.utils.error_reporting import locale_encoding, ErrorString, ErrorOutput
File "/usr/lib/python2.6/site-packages/docutils/utils/error_reporting.py", line 46, in <module>
locale_encoding = locale.getlocale()[1] or locale.getdefaultlocale()[1]
File "/usr/lib64/python2.6/locale.py", line 478, in getdefaultlocale
return _parse_localename(localename)
File "/usr/lib64/python2.6/locale.py", line 410, in _parse_localename
raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: UTF-8

期待されるのは　ja_JP.UTF-8 のような形式なので

$ export LC_ALL='ja_JP.UTF-8'

で定義するとエラーが出なくなります。