CDKとterraformの使い分け

こんにちは、 kotamat です。

少し前から、CDKを用いた環境整備を行いました。今までterraformで構築してきたので、それとの差分をメモ代わりに書こうと思います。

TL; DR

使い分けとしては下記のようになるかなと思っています

  • CDK
    • ベストプラクティスを簡単に構築したい場合。
    • ビルドプロセスなど、動的にインフラ構成を構築したい場合
  • terraform
    • サービスの基盤となるインフラを構築したい場合
    • 同等の環境を、異なるVPCなどで構築したい場合

CDK

とは

AWS クラウド開発キット (AWS CDK) は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースをモデル化およびプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです。

https://aws.amazon.com/jp/cdk/

簡単に言うと、TypeScript、PythonJava、および .NET でCluodFormation(AWS専用のIaCサービス)用のパターンファイルを生成してくれるものとなります。 いつも使い慣れた言語を使うことができるため、サーバーサイドのエンジニアが手軽にインフラの構築を実現できるものとなります。

使用感

今回はTypeScriptを用いたのですが、型推論がしっかり効いていたため、どのリソースにどのようなパラメータが設定可能なのかを、コードをみるだけである程度推測することが可能で、流れるようにコードを書くことができました。

const app = new cdk.App()
new ApiStack(app, 'Api', {
  env: {
    account: 'account',
    region: 'ap-northest-1'
  }
})
app.synth()

class ApiStack extends cdk.Stack {
  constructor(parent: cdk.App, name: string, props: cdk.StackProps) {
    super(parent, name, props)

    const vpc = Vpc.fromVpcAttributes(
      this,
      'Vpc',
      {
        vpcId: 'vpc-8932jkdw',
        availabilityZones: ['ap-northeast-1a', 'ap-northeast-1c'],
        publicSubnetIds: ['subnet-8302sba', 'subnet-32890231'],
        privateSubnetIds: ['subnet-9042389fdjosa', 'subnet-re032109jifds']
      })

    const cluster = Cluster.fromClusterAttributes(this, 'Cluster', {
      clusterName: 'api-cluster-name',
      vpc,
      securityGroups: []
    })
  }
}

このように、<リソース名>.from<設定するアトリビュート>()とすると、現在のリソースから情報を取得し、その取得した結果を別のリソース作成時に使い回すといったことができます。

実行時は下記のようにTypeScriptをJS化した上で通常のJavaScriptを実行するだけなので、環境変数の注入など、動的に指定することが可能です。

cdk synth --app 'node index.js' > ../template.yml

いいところ

上記で紹介したとおり、環境変数などを用いて動的にパラメータを注入できるわけですが、それが生きるポイントとしては、 何かをビルドしたときにインフラを用意する というユースケースが考えられます。

CDKを使っているということは必然的にAWSを用いているということになるわけですが、例えばあるリポジトリでCodeBuildで環境を整備しようとしたときにbuildspec.ymlを配置すると思うのですが、そちらに下記のように指定することによって、dockerイメージを作成したあとにそのイメージを使って環境を作るといったことが可能になります。

phases:
  install:
    commands:
      - npm install -g npm@6.12.0 aws-cdk@1.14.0

  build:
    commands:
    # ... docker build
      - npm ci
      - npm run build
      - cdk synth --app 'node index.js' > template.yml
artifacts:
  files:
    - template.yml

こちらのartifactsを使ってCloudFormationを立ち上げるといった具合です。 この際、例えばCodeBuildに対して特定の条件を分岐させるような環境変数を提供し、それをコード化することによって必要な環境をよしなに作ることができます。

const vpc = Vpc.fromVpcAttributes(
  this,
  'Vpc',
  {
    vpcId: 'vpc-8932jkdw',
    availabilityZones: ['ap-northeast-1a', 'ap-northeast-1c'],
    publicSubnetIds: ['subnet-8302sba', 'subnet-32890231'],
    privateSubnetIds: ['subnet-9042389fdjosa', 'subnet-re032109jifds']
  })
if(process.env.SOME_CONDITION){
  Cluster.fromClusterAttributes() //...ECSを立ち上げる
} else {
  Repository.fromRepositoryName() //... ECRからなにか取る
}

相性のいい環境

上記のようによしなに分岐ができるため、例えば特定の環境のみを再現したい場合の プレビュー環境 や、単純に日頃使い慣れている言語で、サクッと環境を作りたい サーバーサイドのエンジニア などがこの昨日を使うといいかもしれません。

相性が良くない環境

CDKは、 @aws-cdk/aws-ecs-patternsApplicationLoadBalancedFargateService など、便利な関数を呼び出す形で組み立てていきます。 型である程度中を推論できるものの、ハードコーディングされているオプションなどがあり、細かいチューニングには向かないかなと思いました。

Terraform

Use Infrastructure as Code to provision and manage any cloud, infrastructure, or service

https://www.terraform.io/

Terraformのサイトから引用したのですが、文字通り、AWS以外のクラウドインフラにおいて使えるIaCのツールとなります。

使用感

下記のように、独自のDSLを用いて記述していきます。 HashiCorpプラグインなどを使うことによって、設定できるパラメータが何があるかと言うのをある程度推論してくれます。

resource "aws_alb" "default" {
  name = local.alb_name

  security_groups = [
    aws_security_group.alb.id,
  ]

  subnets = data.aws_subnet_ids.main.ids
}

resource "aws_alb_listener" "http" {
  default_action {
    target_group_arn = aws_alb_target_group.default.arn
    type             = "forward"
  }

  protocol          = "HTTP"
  load_balancer_arn = aws_alb.default.arn
  port              = 80
}

実行は基本的にサイト上にあるバイナリファイルをダウンロードしてきて、それを実行していく形になります。

terraform plan # 仮実行
terraform apply # 本実行

実行後はstateというストレージに環境全体の情報が格納され、次回以降の実行時はこのstateと実際のインフラ環境、コードの状況を比較し、差分のみを実行するといったことを行ってくれます。

いいところ

一つ一つしっかり記述していくため、細かいチューニングができるのが特徴です。 また、バイナリの方でフォーマットのコマンドも用意されているため、基本だれが書いても同じようなコードになります。

また、importという機能があり、Webコンソールなどですでに構築されている環境の状態をstateに持ってくる機能があるため、試しにWebコンソールで環境を作ったあと、importでコード化するということができます。

相性のいい環境

基本的に運用し続ける環境で効果を発揮すると思われます。理由としては、

  • 差分適応による効率的な環境設定ができる点
  • import機能による、コード化の簡易性
  • インフラ構築に特化した、宣言型の実装

というところで、メンテナンスに適しているためです。 また、workspaceを用いることによって、本番環境と同等の環境を手軽に別の環境で作成することができるため、本番適応前の最終確認などが手軽に行えるといった点も評価できるポイントです

相性の悪い環境

すべてのパラメータを宣言的に書くという仕様上、あまり動的に変わるようなインフラ環境には向かないと思われます。 動的に変更したい場合はCDKを検討しましょう

まとめ

CDKとTerraformを比較してきました。それぞれ一長一短あると思いますが、よしなに使い分けていけるといいかなと思っております。

元記事

kotamat.com

lernaコマンドの標準出力が微妙な時はstreamオプションをつける

TL;DR タイトル

lernaはモノレポ管理下にあるpackage.jsonのコマンドを同時に実行することができる。

lerna run --scope s-* lint

とするとpackage.jsonのnameがs-で始まるすべてのワークスペースnpm run lintが実行される。(s-はオレオレパッケージのプレフィックスです)

f:id:apple19940820:20200120131838p:plain

モノレポではワークスペースでlintの設定を統一したり、ビルドのコマンドを統一したりするのでlernaのコマンド実行は便利。

しかし問題もなくはない。

標準出力がしょぼい

一部コマンドではルートのpackage.jsonにlernaコマンドを書いて実行すると、Warningになっていても標準出力に出ずsuccess!とだけ表示される。鬱なのでなんとかしたい。

lernaからの実行では一見パーフェクトに見えるが f:id:apple19940820:20200120125453p:plain

ワークスペースに潜ってyarn generateするとバンドルサイズ周りでwebpackが警告出していたという罠 f:id:apple19940820:20200120125604p:plain

--stream オプションをつけて子の標準出力をlernaに送る

runコマンドはオプションで--streamをつけると子プロセスの出力をストリーミングすることができる。各ワークスペースのコマンド実行ログがそのまま流れるため、lernaからの実行時でも重要な標準出力を見逃すことがない。

出力がごちゃ混ぜになってやばいみたいなこともない。

f:id:apple19940820:20200120130206p:plain

他にも並列実行のオプションや実行時のパフォーマンスを測定するオプションもある。需要に応じて使ってみると良いかもしれない。

元記事

ushirock.hateblo.jp

AWS Cloudfront をL7スイッチで使うならTerraform0.12 Dynamicが便利

こちらのブログは個人ブログと同じ内容です

kotamat.com

こんにちは、 kotamat です。

Terraform 0.12がでてしばらく立ちますが、先日構築したCloudfrontの環境において、Terraform0.12のdynamicを使わないと実現できない事案が発生したため、この際にと思い、一気に0.12にバージョンアップしました。

マイグレーション方法とかは、terraform側が提供しているものを使えば80%くらいはやってくれるので(一部手動で修正が必要ですが、WARNING出してくれるのでポチポチやっていくだけです。)今回は主題のdynamicについて紹介します。

Dynamicとは

terraform 0.12で追加されたシンタックスのうちの一つです。 通常、トップレベルのリソースに関しては、一つ一つのリソースに名前をつけて記述したり、 count とかを使って繰り返しを記述していきますが、security groupcloudfront のようなネストされたリソースを記述する際には一つ一つ重複して書く必要がありました。

特にcloudfrontは機能が多く、befaviorに各パスごとのoriginを書くことによってL7スイッチになることができるため、設定が繰り返し記述になりがちであり、かつネストが多い非常に複雑な構造になっているため、dynamicの恩恵を受けることができます。

記述方法

今回は

slides.com

で紹介した形を例に考えてみます。

各種スイッチの向き先の対照表は下記になっています。

ディレクト オリジンの向き先
/api/* API
/nova/* nova
/nova-assets/* nova
/nova-api/* nova
/vendor/nova/* nova
default S3(Nuxt.js)

今までであれば、/apiのブロックを一つ、novaのブロックを4つ、deafultのブロックを一つ書く必要がありましたが、dynamicを用いることによって、defaultとordered一つのブロックですべての表現をすることができます。

resource "aws_cloudfront_distribution" "main" {
// api
  ordered_cache_behavior {
    allowed_methods = [
      "GET",
      "HEAD",
      "OPTIONS",
      "POST",
      "PUT",
      "PATCH",
      "DELETE",
    ]

    cached_methods = [
      "GET",
      "HEAD",
    ]

    default_ttl = 0

    forwarded_values {
      cookies {
        forward = "all"
      }

      headers = ["*"]

      query_string = true
    }

    max_ttl                = 0
    min_ttl                = 0
    target_origin_id       = local.api_origin_id
    viewer_protocol_policy = "redirect-to-https"
    path_pattern           = "/api/*"
  }
// nova
  ordered_cache_behavior {
    allowed_methods = [
      "GET",
      "HEAD",
    ]

    cached_methods = [
      "GET",
      "HEAD",
    ]

    default_ttl = 0

    forwarded_values {
      cookies {
        forward = "all"
      }

      headers = ["*"]

      query_string = true
    }

    max_ttl                = 0
    min_ttl                = 0
    target_origin_id       = local.nova_origin_id
    viewer_protocol_policy = "redirect-to-https"
    path_pattern           = "/nova/*"
  }
// 以下 nova-assets/*とかも記述していく

locals {
  path_patterns = [
    "/api/*",
    "/nova/*",
    "/nova-assets/*",
  ]
}
resource "aws_cloudfront_distribution" "main" {
  dynamic "ordered_cache_behavior" {
    // 何を繰り返すのかをfor_eachで指定する
    for_each = locals.path_patterns
    content {
      allowed_methods = [
        "GET",
        "HEAD",
        "OPTIONS",
        "POST",
        "PUT",
        "PATCH",
        "DELETE",
      ]

      cached_methods = [
        "GET",
        "HEAD",
      ]

      default_ttl = 0

      forwarded_values {
        cookies {
          forward = "all"
        }

        headers = ["*"]

        query_string = true
      }

      max_ttl                = 0
      min_ttl                = 0
      target_origin_id       = local.api_origin_id
      viewer_protocol_policy = "redirect-to-https"
      path_pattern           = ordered_cache_behavior.value // dynamicで指定したリソース名 + .valueでpathの中身を取得
    }
  }
}

他の使いみち

上記はbehaviorの設定をまとめるために使ってみましたが、例えばステージング環境は特定のパスだけBasic認証いれたいという要件が来たときには、今までだとlambda_function_associationだけ違う別リソースを記述する必要がありましたが、mapと組み合わせる事によって、下記のように同一ソースで記述することができます。

locals {
  lambda_associations = {
    "stg": {
      // stg特有のもの(Basic認証とか)
      {
        event_type = "viewer-request"
        lambda_arn = module.viewer_request.qualified_arn
      },
      // prodと共通のもの
      {
        event_type = "origin-request"
        lambda_arn = module.origin_request.qualified_arn
      },
    },
    "prod": {
      {
        event_type = "origin-request"
        lambda_arn = module.origin_request.qualified_arn
      }
    }
  }
}

resource "aws_cloudfront_distribution" "main" {
  default_cache_behavior {
    dynamic "lambda_function_association" {
      for_each = local.lambda_associations[terraform.workspace] // workspaceの値を取得し、動的にassociationを切り替える
      content {
        event_type = lambda_function_association.value.event_type
        lambda_arn = lambda_function_association.value.lambda_arn
      }
    }
  }
}

まとめ

terraform 0.12 dyanmicの使い方を、Cluodfrontを用いて紹介させてもらいました。 特に後者の、lambda edgeとの組み合わせは非常に使い勝手がいいので、よかったら試してもらえればと思います。

macOS Catalinaでもphpenv使いたかったのでdefault_configure_optionsいじったりPHP_BUILD_CONFIGURE_OPTS指定したりした

techblog.roxx.co.jp の続きです。

前回はphpenv, php-buildを諦めてしまいましたがいろいろ設定を調査して再挑戦です。

github.com

default_configure_options を調整する

php-buildには default_configure_options というファイルがあり、こちらに configure で利用するオプションを記載しています。 $PHPENV_ROOT/plugins/php-build/share/php-build/default_configure_options をお好みのエディターで編集し、前回エラーが出ていたzlib, bzip2, iconv のオプションを調整します。

default_configure_optionsはこのようになりました。 gist.github.com

それぞれビルド用にHomebrewでインストールしておきましょう。

brew install bzip2 libiconv zlib

これで再度php7.2.22のインストールに挑戦してみましたが libedit を再インストールしろというエラーが起きてしまいました。くやしい。

$ phpenv install 7.2.22
[Info]: Loaded extension plugin
[Info]: Loaded apc Plugin.
[Info]: Loaded composer Plugin.
[Info]: Loaded github Plugin.
[Info]: Loaded uprofiler Plugin.
[Info]: Loaded xdebug Plugin.
[Info]: Loaded xhprof Plugin.
[Info]: Loaded zendopcache Plugin.
[Info]: php.ini-production gets used as php.ini
[Info]: Building 7.2.22 into /Users/jiska/.anyenv/envs/phpenv/versions/7.2.22
[Downloading]: https://secure.php.net/distributions/php-7.2.22.tar.bz2
(中略)

-----------------
|  BUILD ERROR  |
-----------------

Here are the last 10 lines from the log:

-----------------------------------------
configure: error: Please reinstall libedit - I cannot find readline.h
-----------------------------------------

とりあえずlibeditをインストールしてdefault_configure_options に --libedit を指定して再実行しましたが状況が変わりませんでした。

brew install libedit
$ phpenv install 7.2.22
(中略)

-----------------
|  BUILD ERROR  |
-----------------

Here are the last 10 lines from the log:

-----------------------------------------
configure: error: Please reinstall libedit - I cannot find readline.h
-----------------------------------------

くやしい。もうちょっと原因調べないとダメです。

PHP_BUILD_CONFIGURE_OPTS を指定する

php-build のコードを読んでいて気づいたのですが、macOSの場合は --libedit を上書きしてしまっているようです。

https://github.com/php-build/php-build/blob/a73138438907cc2cfefc8279102ccba234c85369/bin/php-build#L621-L627:該当箇所へのリンク

    if is_osx; then
        configure_option -D "--with-gettext"
        configure_option -D "--with-readline"
        configure_option "--with-libedit"

        configure_option -R "--with-png-dir" "/usr/X11"
    fi

そして、envに PHP_BUILD_CONFIGURE_OPTS を指定すればconfigureにオプションとして反映してくれるようです。

https://github.com/php-build/php-build/blob/a73138438907cc2cfefc8279102ccba234c85369/bin/php-build#L135:PHP_BUILD_CONFIGURE_OPTSが存在しなければ空文字で初期化している

[ -z "$PHP_BUILD_CONFIGURE_OPTS" ] && PHP_BUILD_CONFIGURE_OPTS=""

https://github.com/php-build/php-build/blob/a73138438907cc2cfefc8279102ccba234c85369/bin/php-build#L652:指定したoptionsは最終的にマージされる

    CONFIGURE_OPTIONS="$CONFIGURE_OPTIONS $PHP_BUILD_CONFIGURE_OPTS $CONFIGURE_OPTS"

envにlibeditの設定を指定して再度実行してみたところ、ようやくbuildすることができました!ビルドを試したのは7.2.22, 7.2.23, 7.3.12 です。

# 7.2.22
$ PHP_BUILD_CONFIGURE_OPTS="--with-libedit=/usr/local/opt/libedit" phpenv install 7.2.22
(中略)
Generating phar.php
Generating phar.phar
PEAR package PHP_Archive not installed: generated phar will require PHP's phar extension be enabled.
directorytreeiterator.inc
clicommand.inc
directorygraphiterator.inc
invertedregexiterator.inc
pharcommand.inc
phar.inc

Build complete.
Don't forget to run 'make test'.
(中略)

[xdebug]: Installing xdebug configuration in /Users/jiska/.anyenv/envs/phpenv/versions/7.2.22/etc/conf.d/xdebug.ini
[xdebug]: Cleaning up.
[Info]: Enabling Opcache...
[Info]: Done
[Info]: The Log File is not empty, but the Build did not fail. Maybe just warnings got logged. You can review the log in /tmp/php-build.7.2.22.20191127024529.log or rebuild with '--verbose' option
[Success]: Built 7.2.22 successfully.

# 7.3.12 も大丈夫だった
PHP_BUILD_CONFIGURE_OPTS="--with-libedit=/usr/local/opt/libedit" phpenv install 7.3.12

まとめ

  • default_configure_optionsを調整しよう
  • ビルドに必要なものをインストールしておこう
    • brew install bzip2 libedit libiconv zlib
  • PHP_BUILD_CONFIGURE_OPTSに --with-libedit を追加してから phpenv install しよう
    • PHP_BUILD_CONFIGURE_OPTS="--with-libedit=/usr/local/opt/libedit" phpenv install 7.3.12

最後に

株式会社ROXXでは一緒に agent bankback check を作っていくメンバーを随時募集しています。 この記事を読んでROXXに興味を持ってくれた方はぜひご応募ください。   www.wantedly.com

MySQLのDockerイメージをイチから作成する

backcheck事業部の前田です。
この記事は個人ブログと同じ内容になります。

toyo.hatenablog.jp

わけあって、公式のものとは別にMySQLのDockerイメージを作成しました。
この記事はその備忘録です。

公式のイメージはデータ保存の部分がVOLUMEマウントされているので、イメージの中にデータを含められないからです。

公式イメージではデータを保存できない

Docker環境でMySQLを利用したい場合はMySQLの公式イメージを使用するのが一番ラクで便利です。
ですが、公式イメージではデータを保存しておくことができません。 MySQLではデータを /var/lib/mysql というディレクトリ内に保存するのですが、このディレクトリがVOLUMEマウントの対象になっているためです。

「データをdockerイメージに含めるのはおかしい」という話はもちろんあるのですが、それでも含めたいときがあるじゃないですか。。。というお話です。

試行錯誤してみた

自分で色々とやってみて、たどり着いたのが以下でした。

Dockerfile

FROM ubuntu:18.04

ENV TZ Asia/Tokyo
ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        mysql-server \
        tzdata \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# timezone
WORKDIR /opt
RUN mysql_tzinfo_to_sql /usr/share/zoneinfo > timezone.sql

# mysql
RUN mkdir -p /var/run/mysqld \
    && chown mysql:mysql /var/run/mysqld \
    && usermod -d /var/lib/mysql mysql \
    && mv /etc/mysql/conf.d/mysql.cnf /etc/mysql/conf.d/00_mysql.cnf \
    && mv /etc/mysql/conf.d/mysqldump.cnf /etc/mysql/conf.d/01_mysqldump.cnf \
    && mv /etc/mysql/mysql.conf.d/mysqld.cnf /etc/mysql/mysql.conf.d/00_mysqld.cnf \
    && mv /etc/mysql/mysql.conf.d/mysqld_safe_syslog.cnf /etc/mysql/mysql.conf.d/01_mysqld_safe_syslog.cnf \
    && sed -i -e "s~log_error~# log_error~g" /etc/mysql/mysql.conf.d/00_mysqld.cnf \
    && sed -i -e "s~bind_address~# bind_address~g" /etc/mysql/mysql.conf.d/00_mysqld.cnf

COPY original_mysql.cnf /etc/mysql/conf.d/02_original_mysql.cnf
COPY original_client.cnf /etc/mysql/conf.d/03_original_client.cnf
COPY original_mysqld.cnf /etc/mysql/mysql.conf.d/02_original_mysqld.cnf

COPY entrypoint.sh entrypoint.sh
RUN chmod +x entrypoint.sh

EXPOSE 3306

ENTRYPOINT ["./entrypoint.sh"]

entrypoint.sh

#!/bin/sh

set -e

find /var/lib/mysql -type f -exec touch {} \;

if [ ! -f timezone_applied ];then
  mysqld &
  sleep 3
  mysql -uroot -D mysql < timezone.sql
  mysqladmin shutdown -uroot
  touch timezone_applied
fi

mysqld

ひとつずつ解説していきます。

Dockerfile

FROM ubuntu:18.04

コンテナと言えばAlpine Linuxですが、Alpineのパッケージ管理ツール(apk)では、デフォルトではMySQLをインストールできません。
MySQL互換のMariaDBならインストールすることができますが、MariaDBは認証まわりがMySQLとだいぶ違うため、今回は見送りました。
Alpine以外なら何でも大丈夫だと思います。Ubuntuは私の趣味です。

ENV TZ Asia/Tokyo

TZ というタイムゾーンを指定することで、MySQLタイムゾーンの指定をすることができます。1

ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        mysql-server \
        tzdata \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

MySQLとtzdataをインストールしています。
tzdataはタイムゾーンの情報が入ったパッケージです。
MySQLではデフォルトではタイムゾーンの情報が入っていないため、このtzdataをベースにタイゾーン情報を入れていきます。

また、tzdataをインストールする際に対話シェルが開始されます。
Dockerイメージをビルドする際に対話シェルが開始されると処理が止まってしまうので、 DEBIAN_FRONTEND を指定して対話シェルが開始されないようにしています。

apt使用後はaptに関するデータは不要になるので、最後に使用されていないパッケージや更新されたリポジトリリストを削除しています。

WORKDIR /opt

ここからはファイルを生成したりしていくので、ルートディレクトリから移動をしています。
どこでもいいので、とりあえず /opt に設定しています。

RUN mysql_tzinfo_to_sql /usr/share/zoneinfo > timezone.sql

先ほどインストールしたtzdataの情報をSQLに変換しています。
このSQLはentrypointで使用します。

RUN mkdir -p /var/run/mysqld \
    && chown mysql:mysql /var/run/mysqld \

MySQLのデーモンがpidファイルを作成するディレクトリを作成しています。
また、Dockerイメージをビルドする際は基本的にrootユーザなので、ディレクトリのオーナーもmysqlに変更しています。

    && usermod -d /var/lib/mysql mysql \

mysqlユーザのホームディレクトリが設定されていない場合、 No directory, logging in with HOME=/ というエラーが発生するので、ここでmysqlユーザのホームディレクトリを設定しています。

    && mv /etc/mysql/conf.d/mysql.cnf /etc/mysql/conf.d/00_mysql.cnf \
    && mv /etc/mysql/conf.d/mysqldump.cnf /etc/mysql/conf.d/01_mysqldump.cnf \
    && mv /etc/mysql/mysql.conf.d/mysqld.cnf /etc/mysql/mysql.conf.d/00_mysqld.cnf \
    && mv /etc/mysql/mysql.conf.d/mysqld_safe_syslog.cnf /etc/mysql/mysql.conf.d/01_mysqld_safe_syslog.cnf \

Debian系のLinuxでは、設定をひとつのmy.cnfに書かずに、それぞれの設定をファイルに分割して書きます。 その際にファイル名の順番で読み込まれていきます。
読み込まれる設定の順番を管理するために、デフォルトの設定ファイルに連番のプレフィックスを割り振っています。

ちなみに、 /etc/mysql/mysql.conf.d/ がデーモン寄りの設定が入っており、 /etc/mysql/conf.d/ にクライアント寄りの設定が入っているようです。

    && sed -i -e "s~log_error~# log_error~g" /etc/mysql/mysql.conf.d/00_mysqld.cnf \
    && sed -i -e "s~bind_address~# bind_address~g" /etc/mysql/mysql.conf.d/00_mysqld.cnf

デフォルトの設定のいくつかを無効化(コメントアウト)しています。
Dockerではログファイルにログを吐かれても仕方がないので、 log_error を無効にしています。
また、Dockerコンテナを使う以上、外部ネットワークからの接続を期待するので、 bind_address を無効にしています。

COPY original_mysql.cnf /etc/mysql/conf.d/02_original_mysql.cnf
COPY original_client.cnf /etc/mysql/conf.d/03_original_client.cnf
COPY original_mysqld.cnf /etc/mysql/mysql.conf.d/02_original_mysqld.cnf

自分の作成した設定ファイルをコピーしています。

COPY entrypoint.sh entrypoint.sh
RUN chmod +x entrypoint.sh

自分で作成したエントリーポイントを使用したいため、コピーしてきています。
また、実行可能にするために実行権限を付与しています。

EXPOSE 3306
ENTRYPOINT ["./entrypoint.sh"]

MySQLなので3306番ポートを開き、エントリーポイントを設定しています。

entrypoint.sh

#!/bin/sh
set -e

set -e を指定すると、エラー発生時にスクリプトを止めてくれます。

find /var/lib/mysql -type f -exec touch {} \;

Dockerのストレージエンジン(overlay2)とMySQLの相性が悪いらしく、そのままではCan’t open and lock privilege tables: Table storage engine for ‘user’ doesn’t have this optionというエラーが発生します。
このコメントを参考にさせていただきました。

if [ ! -f timezone_applied ];then

このあとの処理で、タイムゾーンの設定が完了した際に timezone_applied というファイルを作成しています。
つまり、タイムゾーン設定が完了していない場合にタイムゾーンの設定を行っています。

  mysqld &
  sleep 3

mysqldを起動し、起動が完了するまで待機しています。
3秒なのは手抜きです。本当は起動完了しているかどうかを何かしらの方法でチェックする必要があります。

  mysql -uroot -D mysql < timezone.sql

MySQLタイムゾーンのデータをインポートしています。
timezone.sql はDockerfile内で作成しました。

  mysqladmin shutdown -uroot
  touch timezone_applied
fi

mysqldを終了し、 timezone_applied ファイルを作成しています。
これで2回目以降はタイムゾーンの設定がスキップされます。

mysqld

MySQLを実行します。実質のentrypointです。

まとめ

自分でMySQLのイメージを作成してみました。
公式のMySQLのDockerfileがめちゃくちゃ勉強になります。
最初は全く読めないので、こちらの記事がとても参考になりました。

...が意外に便利だった件

はじめまして。
今月からRoxxな人になった前田といいます。 よろしくおねがいします。

PHPでは...というキーワードがあります。

可変長引数と引数のアンパックです。

以下、例です。

<?php
// 可変長引数
function printArgs(...$inputs)
{
    echo $inputs[0]; // apple
    echo $inputs[1]; // banana
    echo $inputs[2]; // chocolate
}

printArgs('apple', 'banana', 'chocolate');
<?php
// 引数のアンパック
function printArgs($a, $b, $c)
{
// 略
}

$args = ['aaple', 'banana', 'chocolate'];
printArgs(...$args);

前から存在は知っていたのですが、わりと自分の中ではただのトリビアになっていて、あまり使用してきませんでした。
というより使用する場面をいまいち把握できていませんでした。

最近、個人で開発しているときに「あれ、意外と...は便利なのでは!?」となったので紹介します。

事例

以下の仕様のクラスを考えます。

  • ユーザ定義クラスStatusがある
  • Statusを複数まとめて扱うクラスがほしい
    • つまり、配列をラップしたクラス
  • 以下の要件を備える

...をつかわない場合

以下のようになると思います。

<?php
class StatusCollection
{
    /** @var Status[] */
    private $items;
    
    public function __construct(array $items)
    {
        foreach ($items as $item) {
            if (!$item instanceof Status) {
                throw new InvalidArgumentException();
            }
        }
        
        $this->items = array_values($items);
    }
}

$items = [Status::on(), Statuss::off(), Status::unknown()];
$statuses = new StatusCollection($items);

ポイントとしては、Status以外の要素がある場合は例外を投げていること、 array_values でキーを振り直しているところです。

こういったバリデーションに近い部分にコードを多く使うと読みづらいですね。

こういった読みづらさを...を使うと解消できます。

array_valuesを取り除く

まず array_values を消していきます。

<?php
class StatusCollection
{
    /** @var Status[] */
    private $items;
    
    public function __construct(...$items)
    {
        foreach ($items as $item) {
            if (!$item instanceof Status) {
                throw new InvalidArgumentException();
            }
        }
        
        $this->items = $items;
    }
}

$items = [Status::on(), Statuss::off(), Status::unknown()];
$statuses = new StatusCollection(...$items);

コンストラクタの仮引数を ... に変更しました。
これにより、キーの採番はPHPが勝手に行うようになるので、array_valuesが不要になります。
また、仮引数を可変長引数にしたので、実引数も忘れずに...でアンパックします。

型チェックのコードを取り除く

次に一番面積をとっているforeachを消していきます。

<?php
class StatusCollection
{
    /** @var Status[] */
    private $items;
    
    public function __construct(Status ...$items)
    {
        $this->items = $items;
    }
}

$items = [Status::on(), Statuss::off(), Status::unknown()];
$statuses = new StatusCollection(...$items);

単純に型宣言(タイプヒント)を使用しています。
...を使う前は配列を受け取っていたのでarrayで指定していましたが、...を使うことで配列の要素の型を指定できます。

面積をとっていたforeachを削除できたので、とても見通しの良いコードになりました。

まとめ

  • ...を使用することで、配列のキーを気にしなくて済む
  • ...を使用することで、配列の要素の型を指定できる

...は型宣言とセットで使用することでパワーを発揮しそうです。 「連想配列じゃなくてもいいんだけど・・・」という場合も結構あるので、配列のキーを気にしなくて良い場合は積極的に使っていこうと思います。

Laravel/Vue.js勉強会#11を開催しました!

株式会社 ROXX の匠平(@show60)です。

先日、10/28にLaravel/Vue.js 勉強会 (通称: Laravue 勉強会) を開催いたしました。

今回は、先月お引越しをされたFABRIC TOKYO様の新しいオフィスにお邪魔して開催いたしました。落ち着いたJazzが流れるキラキラした会場!

今回は Laravue 勉強会の模様を報告いたします!

f:id:show-hei:20191029203435j:plain

LT 登壇内容

スポンサー枠を含め、 6 名の方に登壇いただきました。

それぞれの登壇内容をさっくりとお伝えいたします。

FABRIC TOKYO での Laravel 開発アーキテクチャ

スポンサー枠はFABRIC TOKYOの高橋 (@ssth_jp) さんに登壇いただきました。

f:id:show-hei:20191029203359j:plain

よくある悩みを、チームにおけるクリーンアーキテクチャの解釈を行い解決するというお話をしていただきました。

Laravelのドキュメント通りではなく、DDD、クリーンアーキテクチャを取り入れることで未来の自分が助けられる。

全部を解釈するのは難しいけど、部分的に取り入れることでも恩恵が受けられるよというお話でした。

speakerdeck.com

Laravel で ParaTest を導入する

発表者は弊社のエンジニアのniisan-tokyo(@niisantokyo)です。

f:id:show-hei:20191029203452j:plain

弊社のagent bankというサービスをモノレポ化した際、テストが遅くなってしまったため、解決するためにParatestを導入したところ、Laravel 6.0.2 固有のバグを発見し、解決したという大変貴重なお話です

qiita.com

初めてのプロジェクト参加とDIのお話

同じく FABRIC TOKYO より真嶋 (@shio0594) さんの登壇です。

f:id:show-hei:20191029203520j:plain

初めてプロジェクトに参画された際に、DI(依存性注入)を分かりやすく噛み砕いて理解されたというお話です。

speakerdeck.com

異業種から転職され、サーバーサイドエンジニアとして FABRIC TOKYO で初めてのプロジェクトに入られたそうで、とても分かりやすいスライドと軽快なお話で会場を楽しませていただきました。

PhpStormからLaradock上のPHPUnitを動かしたら開発が捗った話

ザッキー(@ytzk_)さんの登壇です。

f:id:show-hei:20191029203542j:plain

PHPUnitテストが完了するまで時間がかかる、完了するまでエラー箇所が見れないのが辛いという課題に会場のみなさんも頷く、とても共感度の高いテーマでお話いただきました。

speakerdeck.com

詳しい設定方法はこちらの Qiita の記事にまとめていらっしゃいますのでこちらもぜひご覧ください!

qiita.com

Laravel 5.5から 6.4 にアップデートしたときに必要だった7つのこと

青ごへいもち(@blue_goheimochi)さんの登壇です。

f:id:show-hei:20191029203644j:plain

タイトルの通り、アップデートをされた際にどういうエラーが発生し、どうやって乗り越えたかというテーマでお話いただきました。

www.slideshare.net

アップデートでみんなハマりそうな箇所を一つずつ順を追って説明いただきました。分かりやすくまとめていただいているので、これからアップデートされる方には大変ためになる内容です。

過剰なほどに型安全なAxiosラッパー aspida

最後に m-mitsuhide(@m_mitsuhide)さんの登壇です。

f:id:show-hei:20191029203702j:plain

今回は6つの登壇枠の中、唯一のVue.jsのお話となりました。

JavaScriptの世界に存在するカーストのお話で会場を大いに沸かせ、ご自身が開発された aspida というモジュールの発表をしていただきました。

t.co

HTTP リクエストを型安全にし、フロントエンドの開発支援を行うツールです。

実際にライブコーディングでデモンストレーションをしていただき、来場者の方もとても興味深く見ていらっしゃいました。

懇親会

最後はスポンサーのFABRIC TOKYOさんにご用意いただき、参加者同士の懇親会を行いました。

f:id:show-hei:20191029203720j:plain

今後も Laravue 勉強会を行ってまいりますので、最新イベント情報がほしいという方はぜひ connpass のグループへご参加ください!

LaraVue勉強会 - connpass

さいごに

株式会社ROXXでは一緒にサービスを伸ばしていく仲間を募集をしております。

興味のある方は、是非下記からご応募お願い致します!

www.wantedly.com

www.wantedly.com