IDEA Note

  • Linux/Macで好きな容量のファイルを作成する

    Linux/Macで好きな容量のファイルを作成する

    はじめに

    一定の容量のあるただのファイルを作成したいことがたまにある。例えばwordpressのupload容量を変更した際の動作テストを行ったりとかが一例。linuxのみならずmacでもddコマンドで簡単に作成することができるのでその方法を紹介。

    ddコマンド

    linuxもmacも共通の手順はこちら(macで実施した際のログ)

    $ dd if=/dev/zero of=~/80M bs=1 count=83886080
    83886080+0 records in
    83886080+0 records out
    83886080 bytes transferred in 189.533890 secs (442591 bytes/sec)
    $

    80Mの空ファイルが作成される。中身は/dev/zeroなので、からっぽ。

    上記例ではcountはバイト単位になる。

     * 1024 * 1024 * 80 = 83886080
    で80MByteという計算。

    ただし、189.533890 secs とあるように、3分以上かかっている。

    これは1回に読み書きするブロックサイズ(bsオプション)が1になっているため。

    この値を1 -> 1024に変更すれば理論上は1024倍高速になる。

    bsを1 -> 1024に変えてみた

    $ dd if=/dev/zero of=~/80M_1024 bs=1024 count=81920
    81920+0 records in
    81920+0 records out
    83886080 bytes transferred in 0.375389 secs (223464489 bytes/sec)
    $ 

    作成されたファイルは同じく80Mだが、0.375389 secsで完了した。

    bsが1の時と、1024の結果を比較した結果、504倍高速になったが、理論上の1024倍には届かなかった(残念だがそうゆうもんだ。。)。

    意外と知られていないddの使い方

    実はddで送った結果を直接他のサーバに送りつけることもできる。

    dd if=/dev/sda | ssh root@転送先サーバ " dd of=/転送先ディレクトリ/server.sda.img"

    DISKの中身を強制的にddコマンドで吸い上げ、他のサーバにイメージとして保存することもできる。今はDocker含むコンテナ全盛期の時代だが、KVMなどを使えば、吸い上げたイメージを元に仮想サーバとして動かすこともできる。

    参考記事

    https://qiita.com/S-T/items/8de3c150c7097bd021fa


  • docker版redash 運用でよく使うコマンドまとめ

    docker版redash 運用でよく使うコマンドまとめ

    はじめに

    データベースを可視化するのにredashはとても便利。

    しかし、運用を考えるといろいろ考えることがある。
    redashでよく使うオペレーションをまとめた。

    start redash

    cd ~/redash
    docker-compose -f docker-compose.production.yml up -d

    redashのuserを確認

    docker exec -it redash_server_1 ./manage.py users list

    create user

    docker exec -it redash_server_1 ./manage.py users create sumito.tsukada@sumito.jp sumito.tsukada

    change password

    docker exec -it redash_server_1 ./manage.py users password sumito.tsukada@sumito.jp password

    delete redash user

    docker exec -it redash_server_1 ./manage.py users deletesumito.tsukada@sumito.jp

    redash v5以前は、userをdisableする機能がなかったので削除するしかなかったが、一度クエリを作ったり、ダッシュボードを作ると削除できないという問題があった。v5以降は標準でdisableする機能が追加されたので今後使う頻度は減りそう。

    v4以前で上記コマンドでエラーになった場合、redash_postgres_1のレコードを強制的に削除することによって削除が可能になる(ことがある)

    docker ps
    (login to postgress)
    docker exec -it redash_postgres_1 /bin/bash
    psql -U postgres postgres
    SELECT * FROM events WHERE user_id = 6;
    DELETE FROM events WHERE user_id = 6;

    redashデータのexport

    docker ps
    docker exec -it redash_postgres_1 /bin/bash
    pg_dump -U postgres postgres | gzip > /tmp/redash_backup.gz
    exit
    docker cp redash_postgres_1:/tmp/redash_backup.gz .
    

    redashデータのimport

    本作業を行う前に、postgres以外のdockerコンテナを停止する

    docker cp /tmp/redash_backup.gz redash_postgres_1:/tmp/redash_backup.gz
    docker exec -it redash_postgres_1 /bin/bash
    
    psql -U postgres template1
    DROP DATABASE IF EXISTS postgres;
    CREATE DATABASE postgres;
    \q
    zcat /tmp/redash_backup.gz | psql -U postgres -d postgres
    

    Dockerのpostgresのデータをバックアップ

    cronなのに仕込み、定期的に取得する

    /bin/docker exec redash_postgres_1 pg_dump -U postgres postgres | /bin/gzip > /tmp/redash_backup.gz

    参考情報

    オライリー本より読みやすく、Dockerについて体系的に学ぶことができるのでおすすめ。

  • HAproxyでHR構成を組む on AWS

    HAproxyでHR構成を組む on AWS

    はじめに

    DBサーバへ接続する際、readレプリカを複数台作ることが一般的だが、readレプリカに対してバランシングはインフラの設計ポイントとなる。auroraであれば自動でreadレプリカを作ってくれるのでその考慮は要らないがレガシーなシステムを運用している場合それは使えない。今回はAWSで組むこととする。

    やりたいこと

    多くのプログラムはそうであろう構成。

    プログラムは更新用(write)と参照用(read)で接続先を変え、
    データベースはMasterとSlaveでレプリケーションをしている。

    Slaveは今後増える可能性もあるのに加え、Slaveが1台ダウンしてもサービスが稼働できるようにするには、クラスタリング構成をする必要がある。

    クラスタリングソフトの検討

    名前考察
    keepalived名前解決不可能。また、ググっても実績なし
    HAProxyAmazon linuxでyumでのversionが古い(1.5.2)。v1.6の resolvers オプションを使ってVPCのnameserverを参照するようにし、A Recordの変更に追従させる事が可能だが、ソースからのinstallになってしまう
    MySQL Routerアルファ版 本番利用 非推奨
    Consul by HashiCorpググっても出ない
    ProxySQLAmazonLinux非対応

    keppalivedはAWSでは難しいようだ。

    今回はHA proxyで実現することにした。

    対応

    Amazon linuxの上にHAproxyを使いクラスタリングを実現する。

     

    HAproxyのインストール

    amazon linuxの場合、yumでinstallしようとすると、versionが古い。

    そのため、sourceでインストールすることにした

    yum install -y gcc
    cd /usr/local/src/
    wget http://www.haproxy.org/download/1.8/src/haproxy-1.8.8.tar.gz
    pwd
    tar xvfz haproxy-1.8.8.tar.gz
    ls -ltr
    cd haproxy-1.8.8
    make TARGET=generic
    make install
    

    HAproxyの設定

    設定は以下の通り

    $ cat /etc/haproxy/haproxy.cfg 
    global
        log         tsukada01 local2
    
        chroot      /var/lib/haproxy
        pidfile     /var/run/haproxy.pid
        maxconn     4096
        user        haproxy
        group       haproxy
        daemon
        stats socket /var/lib/haproxy/stats
        stats maxconn 1
        stats timeout 120s
    
    resolvers awsvpc
        nameserver vpc 172.20.0.2:53
    
    defaults
        mode        tcp
        log         global
        retries     3
        timeout     connect 10s
        timeout     client 1m
        timeout     server 1m
        timeout     check 10s
        maxconn     512
    
    listen mysql
        bind tsukada01:3306
        mode tcp
        option mysql-check user haproxy_check
    
        balance roundrobin
    
        option          log-health-checks
    
        server read01 dbserver01:3306 check port 3306 resolvers awsvpc inter 2000 fall 3
        server read02 dbserver02:3306 check port 3306 resolvers awsvpc inter 2000 fall 3

    もう片方のサーバは今の通りに設定した

    $ cat /etc/haproxy/haproxy.cfg
    global
        log         tsukada02 local2
    
        chroot      /var/lib/haproxy
        pidfile     /var/run/haproxy.pid
        maxconn     4096
        user        haproxy
        group       haproxy
        daemon
        stats socket /var/lib/haproxy/stats
        stats maxconn 1
        stats timeout 120s
    
    resolvers awsvpc
        nameserver vpc 172.20.0.2:53
    
    defaults
        mode        tcp
        log         global
        retries     3
        timeout     connect 10s
        timeout     client 1m
        timeout     server 1m
        timeout     check 10s
        maxconn     512
    
    listen mysql
        bind tsukada02:3306
        mode tcp
        option mysql-check user haproxy_check
    
        balance roundrobin
    
        option          log-health-checks
    
        server read01 dbserver01:3306 check port 3306 resolvers awsvpc inter 2000 fall 3
        server read02 dbserver02:3306 check port 3306 resolvers awsvpc inter 2000 fall 3

    ほとんど同じように見えるので差分をまとめると、以下のような違いだ

    これで

    • tsukada001の3306ポート
    • tsukada002の3306ポート

      に接続すると、dbserver01,dbserver02へラウンドロビンで接続されるようになった

    しかし、これでは当然tsukada001、tsukada002自体で障害が起きる可能性もある。

    ALBでバランシング

    tsukada001:3306、tsukada002:3306をALBに登録しラウンドロビンで登録した。

    これによりALBのエンドポイントが払い出され、それを各プログラムが参照するような形にして可用性を担保した。

    振り返って見て思うこと

    レガシーなDBでこの構成を組もうとすると、できないことはないが、登場人物がやたら多い。一番なのはauroraなどに移行し、本当に必要なことのみに集中できれば最高だ。

     

     

  • SSL証明書の有効期限を外部から確認する

    SSL証明書の有効期限を外部から確認する

    はじめに

    近年SSL対応したページが当たり前になってきた。AWSであればAWS Certificate Manager (ACM)の機能で自動で証明書を更新してくれるが、念には念を期限くらいは監視しておきたい。また、Let’s encryptを使う環境だと3ヶ月ごとに期限切れになるので、有効期限を監視するのはとても重要だ。外部から証明書の有効期限を確認するコマンドを紹介。

    実施コマンド

    Linuxの場合

    実は非常に簡単に確認ができる

    Linuxの場合はだいたい標準でOpenSSLがインストールされているので、そのコマンドで確認ができる

    openssl s_client -connect tsukada.sumito.jp:443 < /dev/null 2> /dev/null | openssl x509 -text | grep "Not "
                Not Before: Mar 20 09:14:22 2018 GMT
                Not After : Mar 20 09:14:22 2019 GMT

    URLの部分を変えれば、どの環境でも対応できる

    Macの場合

    brewコマンドでインストール

    brew tap genkiroid/homebrew-cert
    brew install cert

    あとはcertコマンドで後ろに確認したいサイトのURLを記載するのみ。シンプル!

    cert tsukada.sumito.jp
    DomainName: tsukada.sumito.jp
    IP:         35.187.235.61
    Issuer:     Let's Encrypt Authority X3
    NotBefore:  2018-07-18 16:45:33 +0900 JST
    NotAfter:   2018-10-16 16:45:33 +0900 JST
    CommonName: tsukada.sumito.jp
    SANs:       [tsukada.sumito.jp]
    Error:      

     

     

  • 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で継続することにした

  • Ansibleで特定サーバのみ振る舞いを変える

    Ansibleで特定サーバのみ振る舞いを変える

    はじめに

    Ansibleで構成管理をしていると、ある全台ではなくある特定のサーバだけ設定を変えたい時がある。WEBサーバ全体ではなく、その中の1台のみ実施したいという時だ。Ansibleのtipsを紹介。

    Ansibleで特定サーバのみ振る舞いを変える

    例えばcronをコメントアウトすることを例にする。

    1. Ansibleのinventoriesのhostsファイルを変更
      以下の通り
      [web]
      web01 ansible_host=192.168.10.10 ansible_ssh_private_key_file=~/.ssh/key
      web02 ansible_host=192.168.10.11 ansible_ssh_private_key_file=~/.ssh/key
      
      
    2. ansible-playlistを編集し、サーバ名を取得する。
      - name: check Hostname
      hostname:
      name: '{{ inventory_hostname }}'
      tags: edit_cron

      inventoriesでいうところのweb01やweb02がこれに該当する

    3. replaceを使う
      特定サーバの場合振る舞いを変える
      web02だけあるcronを変えたい場合
      - name: comment out for 02
      replace:
      path: /var/spool/cron/cronuser
      regexp: '^\* \* \* \* \* echo hello'
      replace: '#* * * * * echo hello'
      when: inventory_hostname is search("02")
      tags: edit_cron

      を定義することにより、02のecho helloだけコメントアウトされる

     

  • redash v5 (5.0) でIn Progress状態のゾンビプロセスをkillする

    redash v5 (5.0) でIn Progress状態のゾンビプロセスをkillする

    はじめに

    重いクエリを投げるとredashが固まってしまい、他のプロセスが起動できなくなることがある。キューを削除する方法を紹介

    前提

    Docker版redash v5 (5.0)

    手順

    dockerにログイン

    docker exec -it redash_redis_1 /bin/sh  

    redisを操作する

    /data # redis-cli 
    127.0.0.1:6379> type query_task_trackers:in_progress
    zset
    127.0.0.1:6379> zrange query_task_trackers:in_progress 0 -1
    1) "query_task_tracker:8b39ba38-7ce9-49f1-8c57-2633ac4bc05b"
    127.0.0.1:6379> zrem query_task_trackers:in_progress query_task_tracker:8b39ba38-7ce9-49f1-8c57-2633ac4bc05b
    (integer) 1
    127.0.0.1:6379> zrange query_task_trackers:in_progress 0 -1
    (empty list or set)
    127.0.0.1:6379> 

    結果

    無事キューが削除された

    最後に

    おそらくversion 5以前でも同様の手順で削除可能

  • 自分のグローバルIPアドレスを確認する

    自分のグローバルIPアドレスを確認する

    はじめに

    内部通信で使うサーバやMacBookのアドレスはOSに付いているip addrなどのコマンドでわかるけど、残念ながらグローバルIPはOSを確認するコマンドはOSに付いていない。外部サービスに問い合わせ、自分のIPを聞くのが一般的だ

    自分のIPを確認する

    ブラウザで確認する場合

    https://www.cman.jp/network/support/go_access.cgi へアクセスすると、接続しているマシンのIPアドレスがわかる。他の拠点のスタッフにIPアドレスを確認するのによく使う。

    CUIで確認する場合

    $ curl -s httpbin.org/ip 
    {
      "origin": "123.12.1.11"
    }
    

    IPのみを取り出したい場合はjqコマンドを使うとIPのみ取り出せる。

    $ curl -s httpbin.org/ip | jq -r .origin
    123.12.1.11

     

  • mysqlのユーザー作成や権限付与の際よく使うコマンド

    mysqlのユーザー作成や権限付与の際よく使うコマンド

    はじめに

    mysqlのユーザーを作成し、権限を適宜設定することが多いがよく使うコマンドをまとめた。

    ユーザーを確認する

    MariaDB [(none)]> select user,host from mysql.user;
    +--------+------------+
    | user   | host       |
    +--------+------------+
    | root   | 127.0.0.1  |
    | redash | 172.18.0.% |
    | root   | ::1        |
    |        | instance-1 |
    | root   | instance-1 |
    |        | localhost  |
    | root   | localhost  |
    +--------+------------+
    7 rows in set (0.00 sec)
    
    MariaDB [(none)]> show grants for 'redash'@'172.18.0.%';

    ユーザーを作成する

    パスワードを平文で入れる

    GRANT USAGE ON *.* TO 'usera'@'192.168.10.10' IDENTIFIED BY 'password123';

    パスワードをハッシュ化して登録

    SELECT PASSWORD('password123');
    #出力されたハッシュを以下に入れる
    GRANT USAGE ON *.* TO 'usera'@'192.168.10.10' IDENTIFIED BY PASSWORD '*6D4B1BD281FE14CCBC97B934';

    権限付与

    参照のみ

    GRANT SELECT, EXECUTE ON `databasea`.* TO 'usera'@'192.168.10.10'

    データ操作言語(DML)文

    GRANT SELECT, INSERT, UPDATE, DELETE, EXECUTE ON `databasea`.* TO 'usera'@'192.168.10.10'

    権限を剥奪する

    全権限を剥奪する

    REVOKE ALL ON `database`.* FROM 'usera'@'%' 

    部分的に剥奪する

    REVOKE DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON `database`.* FROM 'usera'@'%' 

    接続元を変更する

    どこからでもアクセスできた状態からアクセス元を特定セグメントからのみに絞る

    rename user 'usea'@'%' to 'usera'@'192.1.%';

     

    パスワード変更

    すでに作ったユーザのパスワード変更は以下のコマンド

    set password for 'usera'@'192.168.10.10'=password('パスワード');

    ユーザを削除する

    DROP USER 'usera'@'192.168.10.10';

     

  • 無料でhttps化!Let’s Encrypt導入手順

    無料でhttps化!Let’s Encrypt導入手順

    はじめに

    SSL証明書を無料で発行できる時代になった。Let’s enscryptを使えば証明書の有効期間が3ヶ月と極端に短いが、cronなどに仕込めば半永久的に利用が可能。
    今回は、nginxへの組み込みも含めて紹介。

    導入手順

    1 つのドメインへの証明書登録の場合は非常にシンプル。

    ./certbot-auto certonly --no-self-upgrade -n --webroot --agree-tos --email tsukada@test.jp -w /usr/share/nginx/html/sumito -d sumito.jp

    これだけで登録できる。

    Let’s Encryptの証明書は、

    -dオプションでドメインを。

    -w オプションでディレクトリを指定することで複数ドメインを1証明書にまとめることができる。

    以下3つのドメインを1証明書にまとめるとすると、

    • tsukada.test.jp
    • sumito.test.jp
    • coco.test.jp
      手順はこちら。
    cd /usr/local/src
    git clone https://github.com/certbot/certbot
    cd certbot/
    ./certbot-auto certonly --no-self-upgrade -n --webroot --agree-tos --email webadmin@test.jp -w /var/www/tsukada -w /var/www/sumito -d tsukada.test.jp -d sumito.test.jp -d coco.test.jp --expand

    オプションについて

    -w

    -w の部分はドキュメントルートを設定する。ドメイン毎に異なる場合は、-wを増やす。 -w /var/www/tsukada -w /var/www/sumito

    -d

    -dは1枚の証明書に持たせるドメインを入れる場合は、同様に-dを増やす。 -d tsukada.test.jp -d sumito.test.jp

    鍵の作成場所

    以下のディレクトリに作成される

    • /etc/letsencrypt/live/[URL]/fullchain.pem
    • /etc/letsencrypt/live/[URL]/privkey.pem

    nginxの設定

    上記記載の通り、`/etc/letsencrypt/live/`に作成される。

    nginx のserverの設定箇所のところに、以下のように設定することでnginxで証明書を有効化することができる。

    server {
      listen 443 ssl;
      ssl_certificate     /etc/letsencrypt/live/sumito.jp/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/sumito.jp/privkey.pem;
    

    証明書の自動更新

    cronを設定することで証明書の自動更新が可能。 証明書更新後、webサーバを再起動する必要がある。

    0 10 1 * * /usr/local/src/certbot/certbot-auto renew --force-renew && systemctl restart nginx

    参考情報

    15秒でわかるLet’s Encryptのしくみ~無料で複数ドメイン有効な証明書作成~ https://qiita.com/S-T/items/7ede1ccfae6fc7f08393