カテゴリー: kusanagi(wordpress)

  • wordpressのDBをRDSに移行する

    wordpressのDBをRDSに移行する

    はじめに

    wordpressは1台のマシンにmysqlも、wordpress自体もinstallすることはよくあると思う。

    その状態からmysqlをRDSに移行する。

    multi-AZを使うことができるので、DBの可能性が向上するというメリットがある。

    前準備

    mysqlをdumpする

    mysqldump -uroot -p sample_wpdb > sample_wpdb.sql

    移行

    RDSを作成する。

    userを作成する

    RDSを作った際のroot権限を持ったIDでも可能だが、セキュリティを考慮し、1 wordpressあたり、1 user作成すると良いと思う。

    ユーザ作成

    sampleuserを作るとする

    パスワードはpassword123

    database名はsample_wpdb

    SELECT PASSWORD('password123');
    
    GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,ALTER,INDEX,DROP,LOCK TABLES
    ON sample_wpdb.*
    TO 'sampleuser'@'%' IDENTIFIED BY PASSWORD '*xxxxxxxxxxx';

     

    dumpファイルを読み込む

    mysql -uroot -ppassword123 -hsample.ap-northeast-1.rds.amazonaws.com  sample_wpdb < sample_wpdb.sql

    wordpressの設定ファイルでDBの設定を変更

    wp-config.php

    /** WordPress のためのデータベース名 */
    define('DB_NAME', 'sample_wpdb');
    
    /** MySQL データベースのユーザー名 */
    define('DB_USER', 'sampleuser');
    
    /** MySQL データベースのパスワード */
    define('DB_PASSWORD', 'password123');

     

    以上。

     

     

     

     

  • wordpressをLoadBalancer配下にインストールする

    wordpressをLoadBalancer配下にインストールする

    はじめに

    WordPressをインストールする際、ブラウザ越しにポチポチする必要がある。

    しかし、既にLoadBalancerの配下にサーバが存在していて、

    LoadBalancerがHTTPSを受け止め、内部的にHTTPで通信している環境ではこのインストールが非常に悩ましい。

    対処

    この場合bastionサーバ(踏み台サーバ)を利用しプロキシさせる事でHTTPでブラウザ越しに接続する事ができる

    ssh -L Proxyポート:接続先サーバのIP:接続先サーバのPort bastionサーバ
    
    # ex) ssh -L 8080:wordpress-server:80 bastion.sumito.jp

    これで自分の端末とbastionサーバ(踏み台サーバ)がトンネリングを張ることができる。

    自身の端末のブラウザでproxy設定をする

    また、wordpressのインストールの際は、HTTPのリクエストヘッダが重要になる。

    /etc/hostsに以下を記載

    127.0.01    FQDN
    
    # ex) 127.0.0.1   wordpress.sumito.jp

    ブラウザで wordpress.sumito.jp へ接続する事でインストール画面になる。

     

  • ERROR 1045 (28000): Access denied for user ‘root’@’localhost’ (using password: YES)

    ERROR 1045 (28000): Access denied for user ‘root’@’localhost’ (using password: YES)

    はじめに

    kusanagiを使いインスタンスを増やそうとすると、上記のようなエラーに遭う事がある。

    原因

    kusanagiに登録されているmysqlのrootパスワードと、実際のmysqlのrootパスワードに違いがある。

    kusanagiに登録されているrootパスワードを変えるには?

    /etc/kusanagi.d ディレクトリあたりにあるかとおもったら、全く違う所にあった。

    /root/.my.cnf だ。

    [mysqladmin]
    password = "**********"
    user = root

    このpasswordを実際のパスワードに変更する事で、解決することができる。

     

     

     

  • コマンドでwordpressのuserを確認する

    コマンドでwordpressのuserを確認する

    はじめに

    wordpressのユーザー一覧をgit管理したいことがある。
    wpコマンドを使うことで実現可能だ。

    手順

    $ /usr/local/bin/wp  user list --path='/home/kusanagi/cms/DocumentRoot'
    +----+-------------------+-------------------+-------------------+--------------------+---------------+
    | ID | user_login        | display_name      | user_email        | user_registered    | roles         |
    +----+-------------------+-------------------+-------------------+--------------------+---------------+
    | 1  | admin             | admin             | aaa@sumito.jp     | 2013-09-04 01:30:4 | administrator |
    | 12 | design            | design            | bbb@sumito.jp     | 2018-08-21 07:46:4 | editor        |
    | 15 | ccc               | ccc               | ccc@sumito.jp     | 2018-10-01 05:22:5 | ccc           |
    +----+-------------------+-------------------+-------------------+--------------------+---------------+
    $ 
    

    まとめ

    あとは定期的にこの処理をcronのようにjobとして動かし、
    gitへ通知すればスタッフの離職時の棚卸しなどが容易になる。

  • Enhanced networking with the Elastic Network Adapter (ENA) is required for the ‘t3.small’ instance type. Ensure that your instance ‘i-xxxxxxxx’ is enabled for ENA.

    Enhanced networking with the Elastic Network Adapter (ENA) is required for the ‘t3.small’ instance type. Ensure that your instance ‘i-xxxxxxxx’ is enabled for ENA.

    はじめに

    AWSでT3インスタンスがリリースされた。t2.smallを多く使っていたので、似たようなスペックを探したところ、t3.smallインスタンスというのを見つけた。

    t2.smallではCPUが1coreだったのが、t3.smallでは2coreになっているだけでなく安くなっている!

     

    t3.small CPU:2core MEM:2G 0.0272USD/hour
    t2.small CPU:1core MEM:2G 0.0304USD/hour

    https://aws.amazon.com/ec2/pricing/on-demand/?nc1=h_ls

    まさに「うまい、やすい、はやい」というやつだ。インスタンスタイプを変更しない理由はないので、OSを停止できるものから止め、インスタンスタイプを変更していったが、wordpressが動いているkusanagiサーバだけが変更できなかった。

    Enhanced networking with the Elastic Network Adapter (ENA) is required for the ‘t3.small’ instance type. Ensure that your instance ‘i-xxxxxxxx’ is enabled for ENA. が発生

    kusanagiのインスタンスタイプは変更できたが、起動時にエラーになった。

    どうやら Elastic Network Adapterというのがインスタンスで有効になっていないのが原因のようだ。

    では、新しくサーバを立てた場合はどうなるか確認したところ、t3インスタンスは同様の理由でグレーアウトされていた。

    結論

    とりあえずこのサーバだけはt2.smallで継続することにした

  • wordpressの運用でよく使うコマンド

    wordpressの運用でよく使うコマンド

    はじめに

    インフラエンジニアとしてwordpressをいじっていると、よく使うオペレーションの一つが、ステージング環境から、本番環境へデータのコピーだ。逆の場合もある。

    その際、の必要な作業の一つはURLの変更だ。URLをSQLコマンドで変更した。

    コマンド

    以下のコマンドはwordpressのhome/siteurlをhttps://tsukada.sumito.jpに変更するコマンド

    # 現在の設定を確認
    SELECT * FROM wp_options WHERE option_name IN ('home','siteurl');
    
    # home を変更
    update wp_options set option_value = 'https://tsukada.sumito.jp'
    where option_id IN (
    select option_id from 
    (select option_id from wp_options where option_name = 'home' group by option_id  order by option_id ) as tmp);
    
    
    # siteurl を変更
    update wp_options set option_value = 'https://tsukada.sumito.jp'
    where option_id IN (
    select option_id from 
    (select option_id from wp_options where option_name = 'siteurl' group by option_id  order by option_id ) as tmp);
    
    # 現在の設定を確認
    SELECT * FROM wp_options WHERE option_name IN ('home','siteurl');

     

     

     

  • AWSでkusanagi (wordpress高速化マシン) を使う落とし穴

    AWSでkusanagi (wordpress高速化マシン) を使う落とし穴

    はじめに

    AWSで稼働しているwordpressのmysqlが突如down!
    原因を探っていくと、高負荷時にOutOfMemoruになりOOM Killerが発動したことがわかった

    原因

    AWSのkusanagi AMIはデフォルトでswap設定されていない。デフォルトでswapの設定がされてなく、memoryがフルになると、すぐにOOM killerが発動されてしまう

    対処

    swapの設定を適切にした

    cat /proc/swaps
    dd if=/dev/zero of=/swapfile bs=1M count=2048
    chmod 600 /swapfile
    mkswap /swapfile
    swapon /swapfile
    free -m

    fstabにswapfileの設定を追加

    /swapfile   swap        swap    defaults        0   0

    加えてやったこと

    かなり簡易的な監視だけど、もし必要なミドルウェアが落ちてしまった場合、自動で立ち上げるようcronをいれた。

    * * * * * ps ax |grep -v grep | grep -q mysql || sudo systemctl start mysql
    * * * * * ps ax |grep -v grep | grep -q nginx || sudo systemctl start nginx

    その後安定稼働している