IDEA Note

  • CannotStartContainerError: API error (500): failed to initialize logging driver: failed to create Cloudwatch log stream: ResourceNotFoundException: The specified log group does not exist. status code: 400,

    CannotStartContainerError: API error (500): failed to initialize logging driver: failed to create Cloudwatch log stream: ResourceNotFoundException: The specified log group does not exist. status code: 400,

    はじめに

    fargateでタスクを登録し、起動させた時エラーが発生。原因と対処をまとめる

    An error occurs when a task is registered and started with fargate. Summarize causes and actions

    原因

    CannotStartContainerError: API error (500): failed to initialize logging driver: failed to create Cloudwatch log stream: ResourceNotFoundException: The specified log group does not exist. status code: 400,

    CloudWatch のロググループが存在しない

    CloudWatch log group does not exist

    対処

    CloudWatchにロググループを作成する

    Create a log group in CloudWatch

    その後、再度タスクを実行すれば問題は解消できる。

    After that, the problem can be solved by executing the task again.

     

  • nodeのversion管理をnvmで行う

    nodeのversion管理をnvmで行う

    はじめに

    Linux/Macにてnodeのversion管理を手軽に行うよう、nvmで切り替えれられるようにする

    nvmインストール

    nvmのオフィシャルリポジトリはこちら

    https://github.com/creationix/nvm

    ここに記載があるように、installを行う。

    curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.34.0/install.sh | bash

    ~/.bash_profileに環境変数を追加する

    export NVM_DIR="$HOME/.nvm"
    [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
    [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

    変更した~/.bash_profileを読み込む

    source ~/.bash_profile

    stableをインストール

    nvm install stable

    を行うと、stableをインストールすることが可能。

    執筆時のversionは以下の通り

    # node -v
    v11.12.0

    任意のversionをインストール

    nvm ls-remoteコマンドを実施すると、インストール可能なversionが列挙される

    # nvm ls-remote
            v0.1.14
            v0.1.15
            v0.1.16
            v0.1.17
            v0.1.18
            v0.1.19
            v0.1.20
            (略)

    version 8.9.4をインストールする際は以下の通り実施する

    nvm install v8.9.4

    aliasを切り替える

    # nvm alias default v8.9.4
    default -> v8.9.4
    

    version変更を確認

    # node -v
    v8.9.4
    

     

  • mysql 5.7で実行された全クエリをログに出力する

    mysql 5.7で実行された全クエリをログに出力する

    はじめに

    どのようなクエリが実施されたのかトレースする時に使う

    設定

    /etc/my.cnfの設定変更

    general_log=ON
    general_log_file=/var/log/mysqld-query.log

    general_logの記載を追加する

    パーミッション設定

    touch /var/log/mysqld-query.log
    chown mysql:mysql /var/log/mysqld-query.log
    chmod 640 /var/log/mysqld-query.log

    上記設定を入れたら再起動する

    systemctl restart mysqld

    確認

    cat /var/log/mysqld-query.log
    
    2019-03-14T05:39:18.710354Z	    3 Query	INSERT INTO s_bookmark (  id, bookmark_at, 

     

     

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

     

    以上。

     

     

     

     

  • BigQueryのtimestampをUTCから日本時間JSTへ変更する

    BigQueryのtimestampをUTCから日本時間JSTへ変更する

    はじめに

    BigQueryのtimestampの戻り値はデフォルトでUTCである。

    クエリを修正することでJSTを表示できる。

    クエリ

    #standardSQL
    
    select
    created_at as UTC,
    FORMAT_TIMESTAMP('%Y-%m-%d %H:%M:%S', created_at, 'Asia/Tokyo') AS JST
    
    from `BQ.sample`

    結果

    参考情報

    ビッギデータ解析について分かりやすくまとまっているのでおすすめ。

  • EC2(Amazon Linux 2)のディスクサイズをオンラインで拡張する

    EC2(Amazon Linux 2)のディスクサイズをオンラインで拡張する

    作業前

    ディスクサイズを確認する

    $ df -h
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/xvda1       20G   20G  291M  99% /

    Elastic block storeで割り当てDISKを増やす

    何ギガに増やしたいのかサイズを指定する

    (増やす容量ではなく、現在のDISKと併せてトータルの容量にする)

    ブロックデバイスの変更作業

    ブロックデバイスの一覧を表示する

    $ lsblk
    NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
    xvda    202:0    0  40G  0 disk 
    └─xvda1 202:1    0  20G  0 part /

    ブロックデバイスを拡張する

    (ここの手順がAmazon Linux1と2で異なる)

    以下の手順はAmazon Linux2。

    $ sudo growpart /dev/xvda 1
    CHANGED: disk=/dev/xvda partition=1: start=4096 old: size=41938910,end=41943006 new: size=83881950,end=83886046

    ブロックデバイス一覧を表示する。

    変更された事を確認する。

    $ lsblk
    NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
    xvda    202:0    0  40G  0 disk 
    └─xvda1 202:1    0  40G  0 part /

    パーティションを拡張する

    $ sudo xfs_growfs /dev/xvda1
    meta-data=/dev/xvda1             isize=512    agcount=11, agsize=524159 blks
             =                       sectsz=512   attr=2, projid32bit=1
             =                       crc=1        finobt=0 spinodes=0
    data     =                       bsize=4096   blocks=5242363, imaxpct=25
             =                       sunit=0      swidth=0 blks
    naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
    log      =internal               bsize=4096   blocks=2560, version=2
             =                       sectsz=512   sunit=0 blks, lazy-count=1
    realtime =none                   extsz=4096   blocks=0, rtextents=0
    data blocks changed from 5242363 to 10485243

    パーティションが拡張された事を確認する

    $ df -h
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/xvda1       40G   20G   21G  50% /

    参考情報

    https://dev.classmethod.jp/cloud/aws/expand-ebs-in-online/

     

  • go routine/channelを整理する

    go routine/channelを整理する

    go routineのchannelについて勉強したので整理する

    package main
    
    import (
    	"fmt"
    )
    
    // sliceとchannelを受け付ける
    func goroutine(s []int, c chan int) {
    	sum := 0
    	for _, v := range s {
    		sum += v
    	}
    	// channelに送信
    	c <- sum
    }
    
    // channel
    
    func main() {
    	// スライスのinteger
    	s := []int{1, 2, 3, 4, 5}
    	// channel (makeで書く)
    	// makeはキューの働きをする
    	c := make(chan int)
    	go goroutine(s, c)
    
    	// チャネルを受信。ブロッキングの役割があるので、入ってくるまでずっと待っている状態
    	x := <-c
    	fmt.Println(x)
    }

    結果 “` 15 “`

  • 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を実際のパスワードに変更する事で、解決することができる。

     

     

     

  • CloudStorageへAPI経由でファイルをuploadする

    CloudStorageへAPI経由でファイルをuploadする

    はじめに

    Google Cloud StorageへAPI経由でファイルをuploadする。

    Introduction to APIs in Google を受講して、基本的な使い方を覚えたのでメモを残す

    https://www.qwiklabs.com/focuses/3473?catalog_rank=%7B%22rank%22%3A15%2C%22num_filters%22%3A0%2C%22has_search%22%3Atrue%7D&locale=ja&parent=catalog&search_id=2013206

    前準備

    OAuthのアクセストークンを生成する

    https://developers.google.com/oauthplayground/

     

     

    バケットの作成

    頻繁に使うので認証を環境変数に入れる

    export OAUTH2_TOKEN=<YOUR_TOKEN>

    プロジェクトIDも入れる

    export PROJECT_ID=<YOUR_PROJECT_ID>

    バケット生成の定義のjsonファイルを作成、読み込む

    {  "name": "<YOUR_BUCKET_NAME>",
       "location": "us",
       "storageClass": "multi_regional"
    }
    
    
    curl -X POST --data-binary @values.json \
        -H "Authorization: Bearer $OAUTH2_TOKEN" \
        -H "Content-Type: application/json" \
        "https://www.googleapis.com/storage/v1/b?project=$PROJECT_ID"

    画像をuploadする

    wget https://gcpstaging-qwiklab-website-prod.s3.amazonaws.com/bundles/assets/138f92c75d08d0705e3853c1d790453f37fdfff38afad7fb4b431b9fa690f1fc.png
    mv 138f92c75d08d0705e3853c1d790453f37fdfff38afad7fb4b431b9fa690f1fc.png demo-image.png

    フルパスを確認する

    realpath demo-image.png

    結果を環境変数に入れる

    export OBJECT=<DEMO_IMAGE_PATH>

    バケット名を環境変数に入れる
    (先ほど作成したやつ)

    export BUCKET_NAME=<YOUR_BUCKET>

    cloud storageにuploadする

    curl -X POST --data-binary @$OBJECT \
        -H "Authorization: Bearer $OAUTH2_TOKEN" \
        -H "Content-Type: image/png" \
        "https://www.googleapis.com/upload/storage/v1/b/$BUCKET_NAME/o?uploadType=media&name=demo-image"

     

    参考情報

    JSONの構文チェックに便利なサイト

    https://jsonlint.com/

     

    Cloud StorageのAPIリファレンス(英語)

    https://cloud.google.com/storage/docs/json_api/v1/