kikukawa's diary

都内で活動するシステムエンジニアが書いてます。 興味を持った技術やハマったポイント、自分用メモをつけてます。 最近はweb中心

terraformを0.11から0.12にアップグレード

v0.11.11からv0.12.24にアップグレードしたときのメモです。
classmethodさんの記事を参考にしました。

前提

  • アップグレード前はv0.11.11
  • stateファイルはS3で管理されている
  • macOS Catalina
  • tfenv導入済み

0.12checklistの実行

チェックリストコマンドを実行するために
tfenvで v0.11.14 に上げました。
v0.11.14 にしか存在しないコマンドです。

エラー

問題なければ、下記メッセージが出て終わるはずです。

Looks good! We did not detect any problems that ought to be
addressed before upgrading to Terraform v0.12

私の場合は、下記のようなメッセージが出ました。

$ terraform 0.12checklist
After analyzing this configuration and working directory, we have identified some necessary steps that we recommend you take before upgrading to Terraform v0.12:

- [ ] Terraform couldn't reach the Terraform Registry (at `registry.terraform.io`) to determine whether current provider plugins are v0.12-compatible.

  In general, we recommend upgrading to the latest version of each provider before upgrading to Terraform v0.12.

Taking these steps before upgrading to Terraform v0.12 will simplify the upgrade process by avoiding syntax errors and other compatibility problems.

このメッセージでググると、providerをupgradeしたほうがいいというような記事がありましたが、 解決しませんでした。

$ terraform init --upgrade=true

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...

Error installing provider "aws": Get https://releases.hashicorp.com/terraform-provider-aws/: x509: certificate signed by unknown authority.

Terraform analyses the configuration and state and automatically downloads
plugins for the providers used. However, when attempting to download this
plugin an unexpected error occured.

This may be caused if for some reason Terraform is unable to reach the
plugin repository. The repository may be unreachable if access is blocked
by a firewall.

If automatic installation is not possible or desirable in your environment,
you may alternatively manually install plugins by downloading a suitable
distribution package and placing the plugin's executable file in the
following directory:
    terraform.d/plugins/darwin_amd64

そもそもローカルから registry.terraform.io , releases.hashicorp.comping を打っても返ってきません。

ワークアラウンド

ローカルの問題と判断し、dockerコンテナから 0.12checklist を実行しました。
今度は問題なく通りました。

0.12upgradeの実行

あとは参考記事通りに、 v0.12.24 にあげてから terraform init , terraform 0.12upgrade を実行するだけです。

versions.tf ファイルが作成された

backend.tf を作って、そこに required_version を書いてたのですが、 0.12upgrade 実行あとには versions.tf が作成されてました。 backend.tf から required_version は削除しました。

アップグレード後は force_destroy の差分がでなくなった

今回terraformの対象にしていたのはAWSコンソールから手動で作成されたリソースだったのですが、
import後に、planで差分確認だけしている(applyしてない)状態でした。
planでは aws_iam_user に下記差分が出てました。

force_destroy: "" => "false"

force_destroy は、terraform独自のプロパティで、 AWSコンソール上から手動で作ってから、
terraform import を使って後追いするとこの差分がでるようです。

しかし、v0.12にアップグレード後はこの差分がでなくなりました。

FargateとALBの設定メモ

ハマったのでメモしておきます。

最初はECSで assign_public_ip = "true" にしておく

しておかないと、sshで接続でのデバッグが難しいです。 不要になったらfalseにしましょう。

health_check_grace_period_seconds はきちんと設定する

FargateはEC2インスタンスよりも起動に時間がかかります。 なので、余裕をもった値にしておかないと、ヘルスチェックに失敗して、 設定によっては、

立ち上がる -> ヘルスチェック失敗 -> コンテナ終了 -> 立ち上がる -> ・・・

と数分ごとに起動と終了を繰り返すことになりデバッグが辛いです。

LBのターゲットの種類はipにする

デフォルトがinstanceなので注意が必要です。

ヘルスチェックのパスとmacherはよく確認する

当たり前と言えば当たり前ですが忘れやすいのでメモします。 例えばRedashなどログインが必要なものは、 / にアクセスすると /login にリダイレクトします。 このとき、 200 ではなく 302 が帰ってきます。

パスを / に設定したなら、 macherは '200,302' に macherを 200 に設定するならパスは /login にする必要があります。

braviaの録画用HDDを引っ越しする

もともと使っていた録画用HDDの調子が物理的におかしかったので、引っ越しをしました。 HDDらくらく交換ソフト というソフトがsonyから提供はされているのですが、TVが対応していない機種 & Windowsを持っていないので自前であれこれやった覚書です。

  1. 元のHDDより大きいHDDを用意する
  2. 新しいHDDを一応、braviaでフォーマットする(多分いらない工程)
  3. 新旧HDDをubuntuなどに接続する
  4. ddコマンドでクローンHDDを作成する
    • sudo dd if=/dev/sd* of=/dev/sd* bs=16M conv=sync,noerror
      • パスの sd* の部分は各自の環境に置き換え
    • sudo sh -c 'while true; do killall -USR1 dd; sleep 2; done'
  5. 新しいHDDの未使用の領域を使えるようにする
    • GPartedを使う
    • 先頭以外すべてのパーティションの前後を後ろにずらす形で変更する

続・マクアケはこんなところ

この記事はMakuake Development Team Advent Calendar 2019 20日目の記事です。

ここに書かれていることはすべて私見です。

昨年マクアケはこんなところと題してアドベントカレンダーに投稿しました。 今回は続編として、もし自分がマクアケで働きたいと思っているエンジニアならこんなことを知りたいという視点でもう少し具体的に書いてみようかと思います。 昨年の記事に書いたことは全くと言っていいほど変わってないので合わせて読んでもらえるといいかもしれません。 今回の記事に書かれていることが永続的に続くというわけでもないと思うので現状を知るための参考程度にしてもらえればと思います。

いくつかのチームと横断的な動き

マクアケの開発メンバーはいくつかのチームに分かれています。 それぞれが特定のミッションを背負っていて、それを達成するために日々開発しています。 細かいことは書けませんが、技術的に注力するチームとビジネス的に注力するチームがあります。 技術的に注力するチームはプロダクトの安定性やセキュリティ、開発の効率化などを目指してます。 ビジネス的に注力するチームは、目標数字の達成や(いろいろな意味でのユーザーの)プロダクトの使い勝手を改善などを目指しています。

また、チームを横断的に動くメンバーやチームの垣根を超えて協力することも多々あり、チームが分かれているからと動きにくいということもない気がします。 実際私は越境してきたメンバーに助けてもらったことが多々あります。

定期的なLT大会

マクアケでは定期的なLT大会が開催されています。 発表者それぞれが深堀りしたテーマを5-15分程度で発表していきます。 昨年今のオフィスに引っ越してきてから始まり、すでに22回やってます。 毎回軽食と飲み物が用意され、密かに楽しみにしているメンバーもいるようです。

上記定期的なLTとは別に 他社との合同LT大会やメンバーが海外のカンファレンスに参加したときのフィードバック発表なども不定期に開催され勉強会好きの方には合っているんじゃないかと思います。

オフィス

オフィスのレイアウト自体は こちら のときからあまり変わっていません。今の雰囲気だと、こちらの本田さんと中山社長の対談でちらっと社内の様子が見られるのでそちらが参考になるかもしれません。

レイアウトは変わっていないのですが、社内のIT関連を改善するチームが非常に頑張ってくれてていろいろなところの使い勝手が良くなりました。会議室のモニターなんかはワンクリックで出力できたりします。

リモートワーク

一部のメンバーはリモートワークで働いています。 ミーティングがあれば出社しますし、大きめなリリースをした後はしばらく出社している必要があったりなど、完全に自由というわけでもありませんが、リモートワークで働くという選択肢はあります。 ミーティングはすべてがオフラインというわけではなく、Slackの音声やZoomを使ったミーティングもありリモートからの参加が可能な場合があります。

リモートワークだからというわけではなく、相談することで柔軟な働き方ができる可能性は高いです。

まとめ

あくまで業務委託としての私見になりますが、働きやすいし働きがいのある現場だなと思います。

ECSで特定のタスクがINACTIVEで起動しない

困ったのでメモ 起動しないタスクがあってはまりました。

原因は、サービスの下記の値の設定がおかしかったことでした。

  • desiredCount
  • deploymentConfiguration.maximumPercent
  • deploymentConfiguration.minimumHealthyPercent

開発環境で設定したため、最小値でいいだろうということと 他のサービスの値をコピーして何も考えず設定してたため

  • desiredCount:1
  • deploymentConfiguration.maximumPercent:100
  • deploymentConfiguration.minimumHealthyPercent:50

になってました。

  • desiredCount:1
  • deploymentConfiguration.maximumPercent:200
  • deploymentConfiguration.minimumHealthyPercent:100

にしたら無事に起動しました。

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service_definition_parameters.html

マクアケはこんなところ

Makuake Product Team Advent Calendar 2018 の7日目の記事です。
業務委託としてマクアケに参画させてもらってるので書かせてもらいました。
ここに書かれていることはすべて私見です。
マクアケに参画してからもうすぐ2年が経とうとしています。
いい機会なので、マクアケはどんな現場なのかを業務委託観点で書いてみたいと思います。

業務委託としてのスタンス

多分、すべての業務委託が私と同じ感覚を得られるとは思わないので前提として私の業務委託としてのスタンスを書いておきます。
私は業務委託と言っても、何かを命令されてそれを実行するだけというスタンスではありません。雇ってもらっている人、組織に対して最大限自分が出せるバリューをどう提供していくかを考えて動きます。
なので、自分で無駄だ(自分のバリューは出せない、必要ない)と思ったミーティングには参加しないですし、いろいろなところで意見をよく言います。
雇う人によっては扱いづらいタイプかもしれません笑

マクアケには私以外にも業務委託の方はいますが、別のスタンス取っている方もいます。
というか私が特殊だと思います。良い悪いではなく私のスタンスはこうだ。というだけの話です。

マクアケで何をしているか

株式会社マクアケではMakuakeというサービスを開発しています。Makuakeとはなんぞやというのは、こちらに譲るとして私がやっていることを書きます。
2017年の2月に業務委託としてジョインしてからは、Makuakeというサービスを開発してきました。すでに5年運用が続いているサービスだったので、一通りの機能はすでにありましたが、やることはまだまだあって、私がやったのは新機能の開発やリファクタリング、開発フローの改善など様々です。 今現在は、とあるプロジェクトを進めており、そのプロジェクトマネージャーとして動いています。

マクアケはどんなところか

エンジニアが働く上でマクアケはどんなところかを記載します。

開発環境(スペック的な意味)

開発環境はいいと思います。
開発者には、開発するに十分なスペックのマシンが与えられますし、要望すればディスプレイも増設できます。
と言っても、席(物理的な)不足で自由にできない時期もありましたが、会社が移転したのでそれも解決です。 移転のお話については後のアドベントカレンダー出てくると思いますので、お楽しみに。

マシンだけでなく、ライセンスが必要なソフトや技術本も買ってもらうことができます。

エンジニアに理解のある経営陣

私が参画した当初はまだCTOがいない時代でしたが、この記事(ちょっと古いです)からも分かるように技術に理解のある経営陣だと思いました。
今はCTOもいてその理解がさらに広がり、自由な空気感の中で働けるように思います。

業務委託と正社員の区別が薄い

差別のようなものはまずありません。そして区別もすごく薄いです。
さすがに全部が全部同じような権限、行動範囲ではありませんが、ほとんど同じようなことができます。
細かく書くことはできませんが、私にとってはすごく行動がしやすい現場です。

業界が楽しい

単純にクラウドファンディング業界は楽しいです。
クラウドファンディング業界自体がまだ新しく、業界の流れが早かったり新しいものが出てきたりと、業界を知るのが楽しいです。
資金を募るプロジェクトもどんどん増えて来ていて、Makuakeで扱っているプロジェクトを見ているだけで時間が過ぎるときがあります(仕事しろ) 今後まだまだ発展していく業界ですし、今後も楽しみにしています。

いいところばかりではないが変える意思は感じられる

現実世界で事業を行っている以上、いいところばかりではありません。
ただ、それを変えようという意思は感じられますし、私が参画してから変わったところもあります。
今ある課題も、過去から引きずっている課題も、今後起こりうる課題もそういった意思があれば全部解決できるんじゃないかと思ってます。
変える意思のない現場もたくさんあるので、そういう意味ではとてもいいです。

まとめ

基本的に私のスタンスが大きく影響していると思うので、全員が同じように感じるとは思いませんが、エンジニアとして働くにはいい環境だと思います。
興味を持ってくれた人には、「良い現場だよ」と胸を張って言えるし、実際に何人かに声をかけたりしています。私にはなんのメリットもないですが。