「Astroneer」がやりたかった。 ただ、うちには動作条件を満たすWindowsマシンがなくて困った。 ゲームはそんなに長く続かないタチなので100時間もやらないはず。 そのためにわざわざ何万も払ってWindowsマシンを買いたくもないし、大掃除でせっかく空けた家のスペースも使いたくない。 諦めきれずに同僚にslackでAstroneerやりたいと話していたら 「AWSでWindows使えばいいじゃん」と言われた。 その発想はなかった。 調べてみると、海外に同じ事をしている人がいた。 Run your own high-end cloud gaming service on EC2 Revised and much faster, run your own high-end cloud gaming service on EC2! 意を決して作業を始めると、1時間くらいでAstrone

この記事は、「Speee Advent Calendar 2016」の5日目です。 4日目は、id:nisshieeより、「Turbolinks再考」です。 今日は、Terraformの構成について再度考えたいと思います。 先日書いたブログで、hashcorpが公開しているTerraformのbest-practiseについて読み解きました。 takanamito.hateblo.jp ブコメでもいくつかあった「つらそう」という意見 つらさにも種類があるとは思うのですが 僕が実際にベストプラクティスを読んでいて思ったのは モジュールが2階層構造になっており、抽象化されたモジュールを読み解くのがしんどい モジュール単位で変数定義が必要なため、3回変数宣言をしなければならないのがめんどくさい という2点。 ただこれも、多くのリソースを抽象化して管理したり、ファイルの肥大化を防ぐ意味では有用であ

最近、自分のチームでTerraformを使ってAWSのオーケストレーションをやろうという話になった。 サーバー台数も10~20台程度、今まではAWSコンソールをポチポチしてインスタンスを用意していたが サービス規模の拡大に伴って、手動オペレーションによるミスを防いだり、インフラ説明コストなどを省くこと、インフラ整理の意味合いで導入している最中。 Terraformに触るのは初めてだったので、ドキュメントを読みつつ基本的な機能について勉強しつつ どのようなファイル構成で管理をするのがいいのか、経験者の同僚にアドバイスをもらいにいったところ Hashcorpが公開しているベストプラクティスのリポジトリを教えてくれた。 github.com ところがこの構成、けっこう複雑で初心者がいきなり読み始めるのは辛かったので 復習も兼ねてベストプラクティスを読み解いていく。 理解するために必要な要素 AW