投稿者: sumito.tsukada

  • 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

  • JavaScriptの制御をGoogle Chrome側で変更する

    JavaScriptの制御をGoogle Chrome側で変更する

    はじめに

    redash v5のベータ版がお披露目された。注目の機能の一つ、AleartがChatWorkにも飛ばせるようになった。

    しかし

    バグなのだろうか、登録しようとしても有効化しようとしてもSaveが押せない。JavaScript側で制御していて、その制御がおかしいようだ。ベータ版なのでこのような問題もあるのだろう

    対処

    pull requestを投げて解決した。

    と言えればかっこいいが、今回はクライアント(私のブラウザ)のJavaScriptをいじり、無理やり制御を解除した

    JavaScriptの制御をユーザー側で変更する

    Chromeのdeveloper modeを使う

    Macであれば[ Option + command + i ]

    手順は以下の通り

    その後、Saveボタンは無事押すことができるようになり、保存も成功した

    設定したアラートも文字登録された。

     

  • GitLabでCIを動かす

    GitLabでCIを動かす

    はじめに

    Gitと連携させCIを動かす事が増えて来た。GitHubと連携させTravis CIもいいし、Circle CIもいいだろう。GitLab CIのいいところは、自前で環境さえ準備できさえすれば非常に低コスト(IaaSの運用コストのみ)で動かす事ができるのが魅力だ

    設定方法

    前提条件

    GitLabが動作できていること

    本手順は、GitLab 10.3.7を前提としている

    GitLabの設定

    GitLabの左メニューで Settings -> CI/CDを選択する

    General piplines settingsで
    「Instance default」を選択し、Runner Tokenをひかえる

     

    CIサーバ側の設定

    GitLab CIサーバでGitLab runnerの設定をいれる

    # sudo gitlab-runner register
    
    Running in system-mode.
    
    Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
    https://git.sumito.jp/
    Please enter the gitlab-ci token for this runner:
    SJxxxxxxxxxxxx
    Please enter the gitlab-ci description for this runner:
    [server]: projectA
    Please enter the gitlab-ci tags for this runner (comma separated):
    
    Whether to lock the Runner to current project [true/false]:
    [true]: true
    Registering runner... succeeded runner=xxxxxxx
    Please enter the executor: parallels, ssh, virtualbox, docker+machine, docker-ssh+machine, docker, docker-ssh, shell, kubernetes:
    shell
    Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

     

    automatically reloaded!と表示されれば設定は問題ない

    .gitlab-ci.ymlの設定

    .gitlab-ci.yml 
    variables:
    AMI_ID_KUSANAGI: "ami-123456"
    INSTANCE_NAME: "${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_${CI_PIPELINE_ID}"
    TMP_ANSIBLE_DIR: "/tmp/gitlab/${CI_COMMIT_SHA}/${CI_PIPELINE_ID}"
    DEPLOY_SITE: "wordpress"
    SSH_KEY_NAME: "ssh-key"
    INSTANCE_LOG: "/tmp/gitlab/${CI_COMMIT_SHA}/${CI_PIPELINE_ID}/run-instances.json"
    ALLOCATE_ADDRESS_LOG: "/tmp/gitlab/${CI_COMMIT_SHA}/${CI_PIPELINE_ID}/allocate-address.json"
    
    stages:
    - initial
    - build
    - test
    - deploy
    - cleanup
    
    ########################################################
    # STAGE:ANCHORS #
    ########################################################
    
    # These are hidden jobs that contain the anchors
    .server_group_1:
    only: &kusanagi_servers
    /^(wordpress).*$/
    
    ########################################################
    # STAGE:INITIAL #
    ########################################################
    make_tmp_directory:
    stage: initial
    script:
    - mkdir -p ${TMP_ANSIBLE_DIR}
    
    # デプロイテスト用インスタンスを作成@kusanagi& t2.medium
    run_aws_server_kusanagi:
    stage: build
    only:
    - *kusanagi_servers
    script:
    # インスタンスを作成
    - aws ec2 run-instances --key-name ${SSH_KEY_NAME} --image-id ${AMI_ID_KUSANAGI} --count 1 --instance-type t2.medium --security-group-ids sg-12345678 --subnet-id subnet-12345678> ${INSTANCE_LOG}
    # インスタンスにタグ付け
    - instance_id=`jq -r .Instances[].InstanceId ${INSTANCE_LOG}`
    - aws ec2 create-tags --resources $instance_id --tags Key=Name,Value=${INSTANCE_NAME}
    # ElasticIPを払い出してタグ付け
    - aws ec2 allocate-address --domain vpc > ${ALLOCATE_ADDRESS_LOG}
    - allocation_id=`jq -r .AllocationId ${ALLOCATE_ADDRESS_LOG}`
    - aws ec2 create-tags --resources $allocation_id --tags Key=Name,Value=${INSTANCE_NAME}
    # インスタンスのステータスがrunningになるまで待つ
    - i=1; while [ $i -le 120 ]; do sleep 3; if [ "\"running\"" = `aws ec2 describe-instances --instance ${instance_id} | jq '.Reservations[].Instances[].State.Name'` ]; then break; fi; i=$(expr $i + 1); done
    # ElasticIPをインスタンスに紐付け
    - aws ec2 associate-address --allocation-id ${allocation_id} --instance ${instance_id}
    
    # Ansible Playbookをgit clone
    setup_git:
    stage: build
    script:
    - cd ${TMP_ANSIBLE_DIR}
    - git clone git@git.sumito.jp:sumito/projectA.git
    - cd projectA
    - git checkout ${CI_COMMIT_REF_NAME}
    
    ########################################################
    # STAGE:TEST #
    ########################################################
    # 全てのAnsible Playbookの構文チェック
    check_syntax_ansible:
    stage: test
    before_script:
    - sed -e s%__ROLES_PATH__%${TMP_ANSIBLE_DIR}/projectA/Ansible/roles%g /home/gitlab-runner/.ansible_template.cfg > /home/gitlab-runner/.ansible.cfg
    - cd ${TMP_ANSIBLE_DIR}/projectA/Ansible
    script:
    - ansible-playbook -i inventories/staging/hosts sites/staging/wordpress.yml --syntax-check
    
    ########################################################
    # STAGE:DEPLOY #
    ########################################################
    # Ansible Deployを実行
    execute_ansible:
    stage: deploy
    only:
    - *kusanagi_servers
    before_script:
    - elastic_ip=`jq -r .PublicIp ${ALLOCATE_ADDRESS_LOG}`
    - cd ${TMP_ANSIBLE_DIR}/projectA/Ansible
    - sed -si -e s/__IP__/${elastic_ip}/g -e s%__KEY__%/home/gitlab-runner/.ssh/${SSH_KEY_NAME}%g inventories/staging/hosts
    - sleep 20
    script:
    - ansible-playbook -i inventories/staging/hosts sites/staging/${DEPLOY_SITE}.yml -u sumito --limit ${DEPLOY_SITE} --vault-password-file=/home/gitlab-runner/.vault_password
    
    ########################################################
    # STAGE:CLEANUP #
    ########################################################
    # Deployテストしたサーバリソースを削除@on_success
    remove_aws_server_success:
    stage: cleanup
    only:
    - *kusanagi_servers
    before_script:
    - instance_id=`jq -r .Instances[].InstanceId ${INSTANCE_LOG}`
    script:
    - sh /home/gitlab-runner/bin/aws/terminate-instance.sh $instance_id
    after_script:
    - rm -rf ${TMP_ANSIBLE_DIR}
    
    # Deployテストしたサーバリソースを削除@on_failure
    remove_aws_server_manual:
    stage: cleanup
    only:
    - *kusanagi_servers
    before_script:
    - instance_id=`jq -r .Instances[].InstanceId ${INSTANCE_LOG}`
    script:
    - sh /home/gitlab-runner/bin/aws/terminate-instance.sh $instance_id
    after_script:
    - rm -rf ${TMP_ANSIBLE_DIR}
    when: manual

    どのように動くか

    今回実施したPipelineは

    “`
    stages:
    – initial
    – build
    – test
    – deploy
    – cleanup
    “`

    の順番で処理が行われるよう骨格を作った。

    AWSのインスタンスをたちあげ、環境をセットアップし、ansibleを流す。最後にはテストで使ったイメージを削除するPipeline
    gitにpushする度にCIが動くようになり、品質が担保できるようになった。

  • ssh秘密鍵を元に公開鍵を復元する

    ssh秘密鍵を元に公開鍵を復元する

    はじめに

    秘密鍵は手元にあるけど、公開鍵がすぐに出せないということがよくある。
    しかし、秘密鍵を元に公開鍵を作成することは可能だ

    手順

    ssh-keygen -yf 秘密鍵

    リダイレクトすることにより、ファイルに出力が可能

    ssh-keygen -yf  /tmp/id_rsa > /tmp/id_rsa.pub.dump

     

    確認

    オリジナルの公開鍵と、秘密鍵を元に復元した公開鍵の違いはこちら

    [root@tsukada ~]# ssh-keygen -t rsa 
    Generating public/private rsa key pair.
    Enter file in which to save the key (/root/.ssh/id_rsa): /tmp/id_rsa
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /tmp/id_rsa.
    Your public key has been saved in /tmp/id_rsa.pub.
    The key fingerprint is:
    SHA256:HlWiUEHdOU5YteJv38bSB5oXXUQPuxqaubyvJK8dpzs root@tsukada
    The key's randomart image is:
    +---[RSA 2048]----+
    |      .o+o.+ooo..|
    |       . .oo=  +o|
    |        . .o..o..|
    |         . ... ..|
    |        S   o ...|
    |       . . + +o .|
    |        o * ooo= |
    |         *E=o.o.*|
    |        ..X*.. o+|
    +----[SHA256]-----+
    [root@tsukada ~]# 
    [root@tsukada ~]# ls -l /tmp/id_rsa*
    -rw------- 1 root root 1675  8月 17 19:36 /tmp/id_rsa
    -rw-r--r-- 1 root root  393  8月 17 19:36 /tmp/id_rsa.pub
    [root@tsukada ~]# 
    [root@tsukada ~]# ssh-keygen -yf   /tmp/id_rsa > /tmp/id_rsa.pub.dump
    [root@tsukada ~]# ls -l /tmp/id_rsa*
    -rw------- 1 root root 1675  8月 17 19:36 /tmp/id_rsa
    -rw-r--r-- 1 root root  393  8月 17 19:36 /tmp/id_rsa.pub
    -rw-r--r-- 1 root root  381  8月 17 19:36 /tmp/id_rsa.pub.dump
    [root@tsukada ~]# diff /tmp/id_rsa.pub /tmp/id_rsa.pub.dump
    1c1
    < ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDhAoTIS70SmsUKkYp+J11UdnbEqmHmJ1rZP9lbXlP7jDqYZbOKV761CIEtgAuObxNDsr7fh2K0/eH4P+Ie1JB4yFsAQdyQnIqR0BEOT+3DKdSVDJP6ec0iOGl5XrAqbx3rs5pCfUBC3tD8EQHpKOrRHxp7m+o3QnljGtAL0cBMb+3n4dw4Lapq3L0ZOaeXzmuH7efOLT/u6wUQVzWACSZ2z4Jssei22nkJXgXXM6pkV7ejkbNZUppKJZe5drYvW4TJPqKYeAktDr6tnhDJ6n1Qgy3SjWGaDcJ7UKa2CG/84y+I9Et2BXiJaUd5qNMBITx26RDMcNoxTbGSOp1IZwPr root@tsukada
    ---
    > ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDhAoTIS70SmsUKkYp+J11UdnbEqmHmJ1rZP9lbXlP7jDqYZbOKV761CIEtgAuObxNDsr7fh2K0/eH4P+Ie1JB4yFsAQdyQnIqR0BEOT+3DKdSVDJP6ec0iOGl5XrAqbx3rs5pCfUBC3tD8EQHpKOrRHxp7m+o3QnljGtAL0cBMb+3n4dw4Lapq3L0ZOaeXzmuH7efOLT/u6wUQVzWACSZ2z4Jssei22nkJXgXXM6pkV7ejkbNZUppKJZe5drYvW4TJPqKYeAktDr6tnhDJ6n1Qgy3SjWGaDcJ7UKa2CG/84y+I9Et2BXiJaUd5qNMBITx26RDMcNoxTbGSOp1IZwPr
    [root@tsukada ~]# 
    [root@tsukada ~]# 

    公開鍵の後ろに作成したuser@serverが入るのがオリジナル。入らないのが復元した公開鍵。もちろん機能的にはまったく同じく使うことが可能だ

  • 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');

     

     

     

  • hint: Updates were rejected because the tip of your current branch is behind

    hint: Updates were rejected because the tip of your current branch is behind

    はじめに

    git pushすると以下のようなエラーが出てrejectされることがある

    $ git push origin BranchName
    error: failed to push some refs to 'xxxx'
    hint: Updates were rejected because the tip of your current branch is behind
    hint: its remote counterpart. Integrate the remote changes (e.g.
    hint: 'git pull ...') before pushing again.
    hint: See the 'Note about fast-forwards' in 'git push --help' for details.
    $

    原因

    local branchが古い

    対処

    local branchを最新にする必要がある

    $ git pull origin BranchName
    From xxxx
     * branch            xxxx -> FETCH_HEAD
    Auto-merging xxxx
    Merge made by the 'recursive' strategy.
     xxxx | 1 +
     1 file changed, 1 insertion(+)
    $ 

     

     

     

  • invalid header field value “oci runtime error:

    invalid header field value “oci runtime error:

    はじめに

    docker execでコンテナの中に入ろうとした際、以下のようなエラーが吐かれ、中には入れなかった。

    # docker exec -it redash_postgres_1 /bin/bash
    rpc error: code = 13 desc = invalid header field value "oci runtime error: exec failed: container_linux.go:247: starting container process caused \"process_linux.go:75: starting setns process caused \\\"fork/exec /proc/self/exe: no such file or directory\\\"\"\n"
    # 

     

    対処

    yum updateしたら直った。。

    原因

    Dockerが古かった??

  • VyOSでルーティングを設定する

    VyOSでルーティングを設定する

    はじめに introduction

    CiscoライクなオープンソースのVyOSというOSSのrouterがある。
    メインのクラウドがAWSやGCPであればVyOSを使わなくてもよいが、さくらインターネットなどで作業をする際は、まだまだVyOSのお世話になることが多い。よくある手順をまとめた。

    There is an OSS router called Cisco-like open source VyOS. If your main cloud is AWS or GCP, you don’t need to use VyOS, but when you work on the Sakura Internet, there are still many things to take care of for VyOS. Summary of common procedures

    前提条件 Prerequisites

    IPは以下の通り

    IPs are below

    IP
    Global IP 200.20.0.2
    host192.168.0.11
    接続元IP100.10.0.1

    GlobalIPを追加する Add GlobalIP

    追加するシステム(サーバ)に新しいGlobalIPを追加。今回は200.20.0.2/32を新しく追加する

    New GlobalIP is added to the system (server) to be added. Add 200.20.0.2/32 this time.

    # 使用するグローバルIPを定義
    # Define global IP to use
    set interfaces ethernet eth0 address '200.20.0.2/32'

    ポートフォワードの設定 Port forward settings

    “` 200.20.0.2:443“` に来たアクセスを、“` 192.168.0.11:443 “` に送る。今回はポートの変換を行わないが、この設定を変更することにより、サーバに届くポートを変更することが可能。

    Send the access that came at “` 200.20.0.2:443“`  to “` 192.168.0.11:443“`. This time, port conversion is not performed, but it is possible to change the port that reaches the server by changing this setting.

    set nat destination rule 100 destination address '200.20.0.2'
    set nat destination rule 100 destination port '443'
    set nat destination rule 100 inbound-interface 'eth0'
    set nat destination rule 100 protocol 'tcp'
    set nat destination rule 100 translation address '192.168.0.11'
    set nat destination rule 100 translation port '443'

    ※ rule 100の番号はユニークな値にすること

    * The rule 100 number must be a unique value.

    Firewall設定 Firewall settings

    設定したルーティングを全ての人に使わせず、限られた人のみ使わせたいことがある。今回は接続元のIPを限定する方法。 接続元 “` 100.10.0.1 “` からの接続のみ、“` 192.168.0.11:443 “` へ接続許可する

    There are times when you want to use only the limited people without using the set routing. This time, the method of limiting the connection source IP. Only connections from the connection source “` 100.10.0.1“`  are allowed to connect to “` 192.168.0.11:443“`

    # インターネット側からVyOSに対するファイアウォールを設定
    # Set firewall for VyOS from internet
    
    # 接続元100.10.0.1からの接続のみ、192.168.0.11:443へ接続許可
    set firewall name FW-eth0 rule 100 action 'accept'
    set firewall name FW-eth0 rule 100 destination address '192.168.0.11'
    set firewall name FW-eth0 rule 100 destination port '443'
    set firewall name FW-eth0 rule 100 protocol 'tcp'
    set firewall name FW-eth0 rule 100 source address '100.10.0.1'

    ※ rule 100の番号はユニークな値にすること

    * The rule 100 number must be a unique value.

    アウトバウンドのIPを設定 Set outbound IP

    この設定をしないと、インターネットの外にパケットが出て行くことができない。今回は“` 192.168.0.11“` のローカルIPを、グローバルIP “` 200.20.0.2 “`に変換する。

    Without this setting, packets cannot go out of the Internet. This time, the local IP of “` 192.168.0.11 “`  is converted to the global IP “` 200.20.0.2“`

    set nat source rule 100 outbound-interface 'eth0'
    set nat source rule 100 source address '192.168.0.11'
    set nat source rule 100 translation address '200.20.0.2'
    

    ※ rule 100の番号はユニークな値にすること  

    * The rule 100 number must be a unique value.

  • Docker版 redashをv5 (5.0) へupdate!

    Docker版 redashをv5 (5.0) へupdate!

    はじめに

    redash v5 (5.0)がリリースされた。

    https://discuss.redash.io/t/v5-beta-is-now-ready/2240

    今までは4.0.0-rc.1(ほぼlatest)を使っていたが、v5へupdateしたときの手順を記す。

    手順

    PostgreSQLのバックアップを取得

    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の停止

    # docker-compose -f docker-compose.production.yml down
    Stopping redash_nginx_1    ... 
    Stopping redash_server_1   ... 
    Stopping redash_postgres_1 ... 
    Stopping redash_worker_1   ... 
    Stopping redash_nginx_1    ... done
    Stopping redash_server_1   ... done
    Stopping redash_postgres_1 ... done
    Stopping redash_worker_1   ... done
    Stopping redash_redis_1    ... done
    Removing redash_nginx_1    ... done
    Removing redash_server_1   ... done
    Removing redash_postgres_1 ... done
    Removing redash_worker_1   ... done
    Removing redash_redis_1    ... done
    Removing network redash_default

    docker-composeファイルを修正

    # diff docker-compose.production.yml docker-compose.production.yml.20180808
    10c10
    <     image: redash/redash:5.0.0-beta.b4476
    ---
    >     image: redash/redash:4.0.0-rc.1
    26c26
    <     image: redash/redash:5.0.0-beta.b4476
    ---
    >     image: redash/redash:4.0.0-rc.1
    # 
    

    今までは4.0.0rc.1を使っていたが、そこを

    https://hub.docker.com/r/redash/redash/tags/

    の最新tagに変更した

    PostgreSQLをv5用にconvert

    # docker-compose -f docker-compose.production.yml run --rm server manage db upgrade
    Starting redash_redis_1 ... done
    Starting redash_postgres_1 ... done
    [2018-08-08 01:48:59,768][PID:1][INFO][root] Generating grammar tables from /usr/lib/python2.7/lib2to3/Grammar.txt
    [2018-08-08 01:48:59,850][PID:1][INFO][root] Generating grammar tables from /usr/lib/python2.7/lib2to3/PatternGrammar.txt
    [2018-08-08 01:49:03,702][PID:1][INFO][alembic.runtime.migration] Context impl PostgresqlImpl.
    [2018-08-08 01:49:03,703][PID:1][INFO][alembic.runtime.migration] Will assume transactional DDL.
    [2018-08-08 01:49:03,736][PID:1][INFO][alembic.runtime.migration] Running upgrade 969126bd800f -> 1daa601d3ae5, add columns for disabled users
    [2018-08-08 01:49:03,745][PID:1][INFO][alembic.runtime.migration] Running upgrade 1daa601d3ae5 -> d4c798575877, empty message
    [2018-08-08 01:49:03,761][PID:1][INFO][alembic.runtime.migration] Running upgrade d4c798575877 -> e7004224f284, add_org_id_to_favorites
    [2018-08-08 01:49:03,770][PID:1][INFO][alembic.runtime.migration] Running upgrade e7004224f284 -> a92d92aa678e, inline_tags
    [2018-08-08 01:49:03,777][PID:1][INFO][alembic.runtime.migration] Running upgrade a92d92aa678e -> 0f740a081d20, inline_tags
    [2018-08-08 01:49:03,782][PID:1][INFO][alembic.runtime.migration] Running upgrade 0f740a081d20 -> 71477dadd6ef, favorites_unique_constraint

     

    docker-composeを起動

    # docker-compose -f docker-compose.production.yml up -d
    redash_postgres_1 is up-to-date
    redash_redis_1 is up-to-date
    Creating redash_worker_1 ... 
    Creating redash_server_1 ... 
    Creating redash_worker_1
    Creating redash_server_1 ... done
    Creating redash_nginx_1 ... 
    Creating redash_nginx_1 ... done
    # 

    update確認

    今まで使っていたURLにアクセスすると、v5になったredashに接続が可能

    v5の感想

    Queriesに”Favorites”機能が追加されたり、パラメータをブラウザ経由で設定できたりと今までより使い勝手が向上。


    APIなどの機能テストをした後、本番もupdateしていきたい

    リストア(おまけ)

    今回は使わなかったけど、万が一databaseがおかしくなった場合、バックアップから復元することになる。その際の手順は以下の通り。一度drop databaseしたあと、バックアップしたデータを流し込む

    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
    

    5.0.0-beta.b4476 から 現在のlatestへのupdate (2018/10/3 upadte)

    5.0.0.b4754 から 現在のlatestへのupdateは、docker imageを切り替えるだけで大丈夫なようだ。

    以下のように変更し、docker composeを立ち上げるだけでよい。

    <     image: redash/redash:latest
    ---
    >     image: redash/redash:5.0.0-beta.b4476

    5.0.0.b4754 から 現在のlatestへのupdateではDBのスキーマ変更は不要。