【AWS】EC2のリタイア!?
今回はEC2について、ちょっとあんまりみない現象なのかな？と思い調べてみました。
リタイア!?
なにが起こったかというと、こんなメッセージがEC2のメニューで表示されていた。
なぬ！ってかんじでしたｗ
このインスタンス、AWSコンソールをいじっていたところ、 上記のメッセージを確認。。。
もう少し詳しく調べてみましょう。
詳しく
公式にはこう定義されていました。
インスタンスをホストしている基盤のハードウェアで回復不可能な障害が検出されると、AWS によってインスタンスのリタイヤが予定されます。
ふむふむ。ってことは、なんか致命的なエラーでも出ているのか？
再度EC2のメニューから確認してみたが、そんなことはなさそう。 EB(Elastic Beanstalk)から立てられたインスタンスだったので、ヘルスも確認してみたが別に普通。
なんでだろう？ということで、調査するとどうやらメールが届いているらしい。
確認してみるとこのようなタイトルのメールが届いている。
[Retirement Notification] Amazon EC2 Instance scheduled for retirement.
これですなｗ
詳しく本文を読んでみると、ハードウェア(インスタンス)の劣化が原因で、リタイアの設定がなされたようです。 納得ですね、特に何もインスタンスに対して変更をかけていないと勝手に起こるものらしい。
対応策
今回はEBなので、ポチッとインスタンスもう1つ増やしておけばOK。 対応策については、ルートデバイスタイプによりけりみたいです。 以下に公式ドキュメントを貼っておきます。ドキュメントの下部にルートデバイスタイプ別のアクションが載っています。 それで、対応してみるのがよさそうです。
くれぐれも日付を過ぎてからでは、面倒なことになりかねないので、メールをちゃんとフィルタしておこうと思いました！ いや！そもそもインスタンスをきちんと管理していなと駄目ですねｗｗ
ただ沢山あると忘れがちになりますが。。。
以上.
【リアル 7.1ch】Razer Tiamat 7.1 v2のセッティング!?
ちょっと今回はプログラミング系の記事と離れます!!www
今回はオーディオ系!!
プログラミングとは関係ないのですが、ハード、 つまりデスクトップやラップトップ(ノートパソコン)には関係します！
ただ、今回扱うものとしては、ゲーマーの方や、主にデスクトップで 個人的になんかしている方向けってかんじかもしれません。。
しかも、全然オーディオ系に詳しくないので、間違っている部分もあるかもしれないので、ご承知下さい！！ ※ 完全素人知識です！
この記事を見て、「お！そんなのあるのかー」と、思って頂けるだけで嬉しいです！
さて、
まえおき
私の趣味で今色々と自宅にあるデスクトップとヘッドセットをいじいじしていました。 一応最低限の設定が完了したので、ちょっとまとめてみます。
というのも、最近新しいヘッドセットを購入しました！
そのヘッドセットをまあ買ってみたのはいいものの...
設定だったり、購入を検討しているときにググってみてたのですが、 なかなか一通りの流れを抑えた記事が見つからなかったので残しておこうと思います！
今まで
今までヘッドセットを自宅で使用していたのですが、 そのヘッドセットは、7.1 バーチャルサラウンドサウンド搭載の
Razer Kraken USBという商品を使用していました。
Razer商品なので性能抜群だなあ！と、購入当初は思っていました。 接続もデスクトップのUSBにそのまま接続するだけ。
ただ、使用していくうちに、だんだんヘッドセットにも関心が湧いてきて
もっとおもしろいヘッドセット、高機能なヘッドセット使ってみてええええ
と思いまして、今回........
購入したものは
Razer Tiamat 7.1 v2!!!!!!!!
「かっこいい... やっぱRazerでいくか」
と、思ったので思い切って購入！(Razer信者というわけではないw)
こちらがもう、TRUE 7.1 サラウンドサウンド、つまり、
リアル7.1サラウンドを搭載しているのです！
ヴァーチャルとリアルの違い
サラウンドサラウンドというのは主に2種類あると認識しています。 それが、
- リアルサラウンド
- バーチャルサラウンド
の2つです。
バーチャルサラウンドとは、擬似的に立体的な音の広がりを再現しているものです。例えば、左右のスピーカーが立体的な音を出力している。 リアルサラウンドとは、複数のスピーカーを配置。各スピーカーは、配置された場所の音のみ(正確にはその場所だけの音のみというわｋではないみたい)を出し、ひろがりのある音を楽しむことができます。
リアルサラウンドの方は、よく電気屋のオーディオの隔離されたスペースなんかにあるあれですね、たぶん。
色々と調べるとヴァーチャルの方はもはや一般的？というかソフトを使用しても実現可能な時代になっているようです。
なので、結局リアルサラウンドの方がよりリアルwwwというわけです。
私はすぐに手に入れたくなるので、Amazonで買わず店頭に出向きました。
買う前になにも確認せず行ってしまったのですｗｗｗ
店頭にあるサンプルを見て、
「あれ？ 6本もケーブルあるぞ...」
って気づきましたｗ
1本はUSBでクローマの電源供給用で、他5本は全てマイク端子とオーディオ出力端子のもの。
自分のデスクトップにどれだけの3.5mmジャックがあるかも確認しなかったのですｗ なので、スマホでググって型を調べ、デスクトップを購入した店舗にも電話して確認。
3.5mmにジャックが自分の場合、3本のみ。。。 まじかよ、、、とか思っていたら、店員さんが
「余っている2本のジャックはデスクトップのフロントに端子があるので、延長して繋いで、ソフトで調整したらいけるかも」
とのこと。
なるほどーとその時は思っていたので、延長ケーブルを買って帰宅。
さっそく試したら、明らかに無理やんけ。ｗｗｗｗｗｗｗ
サウンドカード登場
ヘッドセットを選ぶ前にサウンドカードという機械を頭の片隅に覚えていました。 サウンドカードとは、音質の向上や入出力端子の増設などを目的としているもの。
友人にも聞いてみたらサウンドカード必要じゃね？ってかんじだったので、 Tiamat購入した次の日にさっそくまた電気屋に！ｗ
サウンドカードがある棚に行き観察。
今回は事前に調べてたので、多少商品の目利きができましたｗ
サウンドカード自体、内蔵型と外付けがあります。
外付けは名の通り、USB接続でデスクトップに接続できちゃいます。 内蔵はデスクトップをこじ開けて、デスクトップ内部に設置しないといけません。 ただ、店員さんいわく、今の内蔵型は、わりと取り付けが簡単なものが多いとのこと。 ただし、サウンドカード自体に電源の供給が必要なものには注意したほうがいいらしい。
昨日も高い買い物したのに、今日もかよ...と私は外付けの方を購入。
「よし、これでTiamat使えるー」
って思いながらXonarを接続していた矢先....
「ん？ なんか端子変なのある... 」
「.............................」
これはよくテレビの裏側のやつに似ている...
そっこうググる。
これはどうもRCAと呼ばれる端子らしい。
Tiamatの接続できなかったケーブルは、緑色(フロントのR/L)だった。 フロントスピーカーのライトとレフト。 この状態だと音は出るかもしれないが、フロントR/Lはでないとか推測できる。
あーーまじかよーーーー とか思いながら思いついたのは変換すること。
変換ケーブル
1本の3.5mmステレオミニジャックをRCA端子への変換ということ。
あった！
UGREEN 3.5mm 2RCA オーディオ変換ケーブル メス-オス(×2) ステレオ オーディオケーブル 金メッキコネクタ (20cm)
- 出版社/メーカー: UGREEN GROUP LIMITED
- メディア: 付属品
- この商品を含むブログを見る
そっこうで、家の近くに電気屋に走っていきましたｗ
ケーブル商品を前にしてまた気づいたことが。。
これ、さす方とさされる方があるのか。。 まあ当たり前なのですが、もうはやくTiamat使いたすぎて色々とぶっ飛ばしてますｗｗ
これはどうもオスとメスという単語で、この領域では言われているらしい。 (ちょっと想像すると変な気持ちになりますｗ)
わたしが行った店頭に置いてあったのは、変換ケーブルのジャックがメス(言い方正しいか不明)のはなかった。 なのでオスを購入し、中継アダプタも購入。
オーディオ編：中継アダプター｜ＡＶコード製品一覧 | JVC
やっと、やっとだと思って試した。
結果、フロントの右のスピーカーが鳴らない........... 意気消沈......
あきらめなかったｗｗ
ここまできて知らなかったことが色々とわかってきた。
どうやらこうしたジャックやらプラグというものの仕組みを理解してみた方が良さそうだ。
この説明を読んでみると、Tiamat側のプラグはステレオで、 サウンドカードのRCAは、アナログ接続に対応している。
電気屋でかった中継アダプタもステレオに対応しているし、 変換ケーブルもステレオ対応。
あれ？とおもってよーく変換ケーブルの説明みたらiPod用って書いてある！ｗｗｗｗ バカすぎますねｗ まあいーんです、色々わかってきたので。
翌日、ちゃんとした変換ケーブルを購入しに電気屋へ！ わたしはオーディオコーナーに行って、店員さんにやりたいことの説明をし、 JVC CN-140Aというケーブルを購入しました。
これで再度接続してみたら、やっと、ようやく音がでたーーーーー！！wwww
これで、リアル7.1サラウンドを体感できました。
Equalizer APO
最初接続完了してからSUBウーハーが鳴っていないことに気づきました。 どうやら個別に設定が必要なようです。
無料ソフトのEqualizer APOというものをデスクトップにインストール。
設定はわかりやすいこの動画を参考にさせていただきました！！ (本当に知識の共有って素晴らしい...!)
あとは、触っていくうちに自分で好みの設定に近づければ良さそうですね！
まとめ
リアル7.1サラウンドのヘッドセットを購入する際に考慮しておきたいことを挙げます！ あくまで、最低限ということ覚えておいて下さい！
- 欲しいヘッドセットの仕様を確認する
- ヘッドセットのチャンネル数に対して、デスクトップのマザーボードで出力できるチャンネル数を確認する
- デスクトップのイヤホンジャックの数と役割(色など)を確認する
- ヘッドセットのケーブルの役割を把握する (ケーブルが複数ある場合は、どのケーブルがどのスピーカーなのかなど)
- イヤホンジャックに応じて、サラウンドカードの導入を検討する (内蔵/外付け)
- サウンドカードが外付けの場合、端子に注目する(ヘッドセットのプラグと合うかなど)
マザーボードの取替はよっぽどでないと行わないようなので安易に改造を考えないほうがいいみたいです。
とまあ、長くなりましたがこんなかんじ。 本来変換ケーブルとかかませたくないのですが、一旦はよしとしました。
後々、サウンドカードの内蔵型を導入も考えてみようかなと思っています。
かなりノリで乗り切れると考えていましたが、けっこう設定なりが難しいので、 この記事が少しでも誰か役に立てばと思っていますｗ
以上.
【Datadog】入門 Amazon Linuxに導入
今回はDatadogについて簡単に、何ができるかと Amazon LinuxにDatadogを導入する方法を書いていきます。
まず、そもそもDatadogってなにってところからおってみます。
Datadogとは？
サーバなどに関するモニタリング機能(SaaS形式)のサービスです。 ただのモニタリングできるサービスか！ってわけではありません。
使用するとわかるのですが、ビジュアライズが凄い綺麗だったり、 tagを使った多次元解析できて、リアルタイムにサーバーの状況が把握できたりします。
もう少し深追いしてみます。
Datadog Agent
監視を始める前に、ターゲットとなるホスト上にDatadog Agent (ソフト)を動作させる必要があります。 ターゲットホストの情報(イベントやメトリクスなど)を取得し、Datadogに送信します。
Datadogはドキュメントもよく揃っているので、一度は目を通してみてもいいかもしれません。
このDatadog Agentは主に3つの要素で構成されているそうです。
Collector CPUやメモリなどの一般的なシステムメトリクスとIntegrations(後述)の情報を取得。
Forwader CollectorとDogStatsDのデータを受け取り、queueの順番に従ってDatadogに送信する。
ふむふむ、なんとなく想像はつきますね。 少し出てきた、Integrationsについて確認してみます。
Integrations (インテグレーション)
Datadogが提供しているIntegrationsは、他の監視システムでいうとプラグインみたいな位置づけでしょうか。 たくさんのIntegrationsが用意されています。
こんなかんじ↓
Integrationsによっては、Datadog Agentの設定ファイルに追記が必要な場合もあるとのこと。 有名なサービスであれば、設定ファイルの記事も多少あったと思います。
Amazon LinuxにDatadog Agentをいれる
別にAmazon Linux(AL)じゃなくてもいいのですが、けっこうAWS使用している会社も多いと思うので例として。 ほんとに説明する必要ないくらい簡単です。
まず左メニューのIntegrationsクリック(選択肢出てきたらAgentでもOK)して、上タブのAgentでOSの選択画面にいきます。
そしたらALを選択。
すると、インストールコマンドが表示されるので、コピーして、 ターゲットとなるホストにsshなどで接続からの、コマンド叩いて終了です。
実に簡単ですね！！ 導入したのを確認するには、左メニューのinfrastructureをクリック。 導入したホストが表示されているかと思います。画面上部には、こんなかんじで
稼働中ホストの数 Hosts up / 合計ホスト数
今導入されているホスト数が載っているかと思います。
導入後は、自分が見やすいようにダッシュボードやモニターを設定していきます。
ダッシュボード
私も機能を使い切れていないので、ドキュメントを貼っておきます。
こんなことできるよ！というのはこの方の記事が日本語でよくまとまっています！
こうした設定方法は、後々また記事にできればいいなと思っています！ けっこう監視初めてだと、どうした設定をしていけばいいのか、 どこから手をつけていいのかわからない場合が多いような気もするので、 そこらへんも含め次回以降の記事にまとめていけたらと思っています！
以上.
【AWS】シンプルなリリースプロセス自動化 ( Github + CodePipeline, CodeBuild, Elastic Beanstalk )
今回はAWSを使用したシンプルなリリースプロセスの自動化について考えてみます。
リリースプロセスとは、開発から本番サーバーまであげていく(= リリース)ことをここでは指します。 また、たーっくさんのノウハウがあるので、この記事ではあくまでも一部。 やり方、状況1つでけっこうな構成が考えられるので、そこはググってみて下さい。 また、この記事ではAWSコンソールの画像は載せないので、ご自身のAWSコンソールで確認しながら用語など確認してみて下さい。 今回の記事では、本番というかステージサーバーまでというイメージになりますが、一旦構成できてしまえば、本番も簡単ですので、一読頂けたら幸いです。
まず、Code3兄弟
AWS界隈では、よくCode三兄弟なんて呼ばれているサービスがあります。
そのサービスとは、
- CodeCommit
- CodeDeploy
- CodePipeline
この3つのことです。
DynamoDBやS3は知ってるけど、この3つは使ったことないという方も多数いるのではないでしょうか。 自分の会社でもし使用しているのであれば、是非構築した人にどうしてこの構成にしたのかなど聞いてみると面白いかもしれません！ もしかすると、苦悩など聞けるかもしれません。。。ｗ
また、上記のサービスと合わせて、Jenkinsというツールを使用されている方も多いのでは？ けっこう記事も多くありますしね。
ただ、私としてはAWS内のサービスでまかなえたらと思います。
理由は、ただ面倒くさいから....w
この3兄弟についてはざっくりこんなかんじです。
CodeCommitは、AWS版Git。 CodeDeployは、EC2へのファイル配置とスクリプト実行を自動で、プラスで環境毎で管理しやすいよ。 CodePipelineは、アプリのビルドやテストのフローを管理・自動化してくれるよー。
みたいなかんじです。
あれ？タイトルのCodeBuildは？
こちらは2016年のre:Inventにて、発表されたサービスのようです。 もう2年くらい経っているので、今ではCode4兄弟になっているようですｗｗ
一旦、Codeなんちゃらと言われるサービスは、リリースまでの手助けをしてくれるものとしてざっくり覚えておけばよさそうですね。
(※ コード書くとかほんとに全てAWSで収めたい場合、CodeStarと呼ばれるサービスもあります。参考 )
CodeBuildもざっくり言うと、フルマネージド型ビルドサービス。(自分でビルドサーバーを管理しなくていい)
うんうん。まあ、一旦公式のドキュメントを以下に。
そして今回は、タイトルにもある通り、
Github + CodePipeline + CodeBuild + Elastic Beanstalk
でかるく流れを追いつつ構成を考えてみます。
前置き
いきなり各サービスを作成していってもいいのですが、面倒なことになりかねないので一旦前知識として！
開発環境について
主にWebアプリだと仮定して、開発だとローカルに仮想環境を構築されている方多いと思います。 CentOSだとかDockerとかですかね？ ここではDockerということにします。
ローカルでバグ修正なり、開発を終えると大体先輩やらのコードレビューが入ります。
何でコードを管理しているかによりますが、ここではGithubにします。 大体ブランチを切ってプルリク出してmasterにマージします。
まず、ここで把握しておきたいのは、CodePipelineをキックするのはどのブランチになるかということです。
ここでもう、どんなかんじはフローになるのかを見てみます。
いったん構成図をみてみる
これさえ見たらもうわかるかと思います。 CodePipelineが管理する管轄は、この3つのサービスです。 (上の構成図では、Githubは点線の外ですが基本的には、CodePipelineを作成する際に、認証接続が必要になります。)
ここでもう一度言います！ あくまで、シンプルな構成図です！ ビルドしてからのテストや、承認アクション、Slackに通知したりなどなどいくらでもできるのですが、まずは基本ということで、シンプルでいきますｗ このシンプルな構成ができれば、あとのカスタマイズは楽になるかと思います。
Docker Imageを確認してから....
さて元に戻って...
開発でDockerを使用しているならば、必ずDockerfileなるものを管理していると思います。
そのDockerfileを元にdocker buildなどなどしているはずです。
ローカルでdocker imagesで今どんなイメージ使用しているか確認します。
何故確認するかというと、実はもう1つAWSのサービスを使うためです。
CodeBuildで必要になってきます。 現在のCodeBuildでは、ビルドをする環境イメージがUbuntuしか選択できないのです。 なので、せっかくDockerで開発しているならばそのままDockerイメージを選択してそのままテストできた方がいいですよね。
なので、Dockerfileの内容をきちんと確認しておきます。 そしたら新しく使用するサービスは、ECR (Elastic Container Registry)というサービスです。 簡単に、AWSのDockerレジストリサービスのことです。
Docker Imageを管理しておくことができます。
ということで、まずDocker ImageをECRで管理します。
ECRへプッシュ
特に難しいことはなく、コマンドを打てばECRにイメージが登録できます。
基本的にAWSコンソールの方で先にリポジトリを作成します。 作成が完了すると、コマンドの例が出てくるのでそれを順を追って叩いていけば問題ないです。
1つ、aws cliを使用できるように自分設定しなければなりません！
最終的に以下のようなコマンドを打ち終わると登録完了できたと思います。
$ docker push 506445657567.dkr.ecr.ap-northeast-1.amazonaws.com/docker-image-name:version
ちゃんとヴァージョンを指定してあげましょう！ もし間違えても完全新規なら特に影響する範囲がないので、間違えたら削除すればいいや程度で叩いてみても大丈夫でしょう。
ECRを加えることで、以下のような構成図になります。
ようやく、流れを確認 !w
まず、今回の記事の場合だと以下の手順で構成し始めるといいかもしれません。
- 開発環境を確認する (Dockerまわり、Githubブランチまわりなど)
- ECRにDocker Imageを管理させる
- CodeBuildでプロジェクトを作成する
- ElasticBeanstalkでアプリと環境(最低1つ)を作成する
- CodePipelineでそれぞれのサービスを紐づけしていく
- それぞれ動作するか確認〜
どんな環境でどんなサービスなのかによっても左右されますが、ちょっと詰まりやすいのは、 CodeBuildが正常にいくかなのかな〜と思います。
あと、ElasticBeanstalk(以下EB)で先に現状のプロジェクトをEBの各言語のルールに沿ってそのままzip化して、 そのまま手動で挙げてみて、とりあえず正常に動作するか確認してもいいかもしれません。
そしたら、簡単にはなりますがいくつかサービスの詳細を書いていこーかと思います。
CodeBuildについて
記事の前半にある前知識で、Githubの指定したブランチに対して、CodePipelineがキックされて成功なら、次にCodeBuildに流れていくことが大体わかったかと思います。
CodeBuildのプロジェクトを作成するにあたって重要な項目は以下。
- ソース:ビルドの対象 > ソースプロバイダ
- 環境: ビルド方法 > カスタムイメージタイプ(Docker)
- buildspec 名
- サービスロール
- VPC (環境によりけり)
- 詳細設定全般(特に環境変数かな？)
大体想像できるかと思いますが、buildspecが見慣れないかんじがします。 これは、ビルドを仕様をYAML形式で指定できるものになります。
AWS CodeBuild のビルド仕様に関するリファレンス - AWS CodeBuild
主に以下のようなかんじで記述していきます。 術全ての項目が必須というわけではないので、必要なところだけ記入してプロジェクトのプロジェクト直下に配置します。
version: 0.2
env:
variables:
key: "value" #環境変数指定
parameter-strore:
key: "value" # Systems Managerから取得し、値は暗号化できる
phases:
install: # パッケージインストール
commands:
- command
pre_build: # ビルド前処理
commands:
- command
build: # ビルドテスト
commands:
- command
post_build: # アーカイブ化(zipなど), ECRへのプッシュ
commands:
- command
artifacts:
files: # S3へアップするファイルを指定
- location
node.jsならnpm installとか、PHPならcomposer.phar installをここに書いておけば大丈夫です。
と、同時に、前にDockerfileを確認と言っていましたが、CodeBuildではECRに登録したDockerイメージを使用します。 ちゃんとbuildspec.ymlと合わせて、CodeBuildでもDockerイメージが使用できるように調整しましょう！ テストコードもここでコマンドを叩いてテストできるので、1度はとりあえずビルドかけてみるがいいでしょう。
CodeBuildのログ
ログですが、ビルドするとAWSコンソールでビルド履歴が確認できます。
そこの各項目の詳細を開くと、出力:ログからCloudWatchに飛ぶので確認できます。
どこのコマンドでコケているんだ〜とかチェックできます。
Elastic Beanstalk
EBには、大きくアプリとその環境という枠組みを作成することになります。 例えば、1つアプリ作成して、環境を複数作成し、Blue/Greenデプロイ構成を作成することができます。
環境をステージングと本番に分けてもいいですね。
EBの場合はけっこう設定する項目があります。
- 環境枠の選択 (Web環境 or Worker環境)
- 基本設定 > プラットフォーム
- 基本設定 > アプリケーションコード
- さらにオプションを設定 > ソフトウェア / インスタンス / 容量 / ロードバランサー / ローリング更新とデプロイ / セキュリティ / モニタリング / 通知 / ネットワーク / データベース / タグ
ほんとは全て気にしないといけないのですが、特に気にしたのが、ネットワークとロードバランサー(ALB)ですかね〜。
EBだとデフォルトで、Classic Load Balancer (CLB)になってしまいます。なので、ALBに変更します。 CLBではWAFを使用できませんが、ALBは使用できたりします。 ネットワークは、あれです、会社のルール的なやつです...w
上記を設定し、プラットフォームを使用したい言語に合わせてzip化してとりあえず手動であげれば動きます。 ※ 設定内容は環境作成後、変更は可能ですが、インスタンスが新規で作成されたりするので、できれば最初の段階で設定値は運用するにあたっての設定にしといた方が後々楽かと思います。 インスタンスのセキュリティグループの追加でも環境の再構築が始まりました。
とまあ、とりあえずこんなもんかなというEBが作成できてしまえば、設定の保存ができるのでいくらでも環境の作成&削除が可能です。 あんまりこだわっても仕方ないのでね。。ｗ 開発する段階で徐々に調整していくのがいいかもしれません。
.ebextensions
EBには、.ebextensionsというその環境のAWSリソースをカスタマイズできる機能(設定ファイル)を持つことができます。
プロジェクトに.ebextensionsというフォルダを作成し、その中にxxxx.configというファイルをYAMLかJSON形式で書いて、置いておけばいいです。
.configという拡張子で認識するので、ファイル名は任意で複数置くこともできます。
また、JSONで記述可能ですが、公式ではYAML形式を推奨しているようです。
CodeBuildでも設定ファイルあるのに、EBでもか.... と思ってしました。
例としてこんなかんじかけます。(パッケージ入れたり環境変数設定したり立ち上げ時のサーバーにファイル生成したり...)
packages:
yum:
パッケージ名[]
commands:
01-xxxxx-command:
command: なんかコマンド
02-xxxxx-command:
command: なんかコマンド
test: なんかコマンド
files:
"/path/to/you/want/create/file.sh" :
mode: ""
owner: root
group: root
content: |
ファイルの内容
EBのTips
1つ私が詰まって1日費やした箇所があります。 EBの仕組みとして、覚えておかないといけなかったっぽい。。
.ebextensionsをもちろん使用していたのですが、ログを確認するとどうもその記述が悪くあるコマンドでこけていた。。。 エラー内容もよくみるものだし、内容は把握していたのに何故かうまくいかない。。
結論としては、.ebextensionsで記述したコマンドが実行される場所に鍵がありました。
EBがの.ebextensionsが実行される場所は、/var/app/ondeckというディレクトリがワーキングディレクトリになっています。
コマンドが正常に全て完了すると、ondeckディレクトリはなくなって、currentディレクトリにプロジェクトがコピーされ、デプロイの完了になります。
おーーなるほどーーと思い、コマンドを修正したら見事EBのヘルスがOkになりました。。ｗ
ここまで
大体山場を抑えたら、あとはCodePipelineで各サービスを紐づけしていくのみです。 特に難しい操作はありません。ポチポチしていけば、大丈夫です。
Githubの指定したブランチにpushされた時に、CodePipelineが発火します。 AWSのコンソールの進捗状況をみていると、今どこで処理されているのかが確認できます。
まとめ
今回はシンプルな自動化のフローを考えました。 この他、承認フローとして、Lambdaをかませて、Slackのあるチャンネルに通知 > Slack上で任意のユーザーの承認を得る > ステージングに変更を適用などできます。またビルド後のテストのフローもビルド先を増やせば複数できるのかな？
ほんとに色んな方法があるので、いろいろ試してみたいものです！ ただ、他サービスを入れてしまうと運用コストが高くなってしまうので、できるだけシンプルに簡単にを意識したいと改めて思いました。
以上
【AWS】Amazon Linux 2だよ〜
今回は少し内容が薄めです...
既にITに精通している方であればご存知だと思います。
去年の冬にAmazonが公式から発表されました。
これが問題とあんる会社は多いのではないでしょうか？ 問題というか、ヴァージョンの移行にコミットしなければならず、現状行っている作業が中断なんてことも...??
こういうときにエンジニア不足している会社だと大変ですね。。。
1つ例を挙げてみます。
Elastic Beanstalk
Elastic Beanstalkを使用している方は多いかと思います。 また、開発ではDockerを使用していて、例えばこんな風にDockerfileに記述している。
FROM amazonlinux:latest ・ ・ ・ ・
いつも通りにローカル環境を整えていて、
「あれ？ なんか動かないぞ。。。」
なんてこと、あると思います！
これは、 latest と記述しているので、最新のAmazon Linuxヴァージョンを取得しにいっているので、
FROM amazonlinux:1
こんなかんじでヴァージョンの指定しないと、前と同じ環境は作成されません。
DockerのコンテナイメージもAmazon Linux2を提供しています。
いい面もあります。
Dockerを使用しているなら、Amazon Linux2を試すこともできますね。 言語のバージョンも合わせてアップデートするなら今のうちかもしれません。。。
また、こちらの記事にAmazon Linuxとの違いがうまくまとまっている記事があります。
Amazon Linux 2 の登場と、Amazon Linux との違い、移行方法などをQ&Aから抜粋したメモ
Amazon Linux2とAmazon Linuxの違いについて（メモ）
Amazon Linux自体はこちらのヴァージョンを最後としています。
利用可能になりました – Amazon Linux AMI 2017.09 | Amazon Web Services ブログ
今のヴァージョンの最終的なサポート期間は、 セキュリティアップデートはAmazon Linux 2の最終LTSビルドが発表されてから2年間提供されます。
あっという間というかんじですね..
ひとまず、何か新規プロジェクトを構成するならAmazon Linux2ですね！！
以上.
【npm】configパッケージについて
よくnode.jsで開発しているとconfigパッケージを使用して、 環境別の設定値を切り分けることが多いと思います。
DBの接続情報であったり、APIとかも環境によってわけて使う時などに便利です。
使い方も簡単ですよね！
$ npm install config
あとは、/config というディレクトリを作成して、
環境名のファイルを作成するだけで、コード内で config.get('xxxx.yyyy') みたいに書くだけで値を参照できます。
nodeのプロジェクトをやっていてこのconfigは便利なのですが、 よくdefault.jsonとdevelopment.jsonはどちらが優先されるの？ とか、上書きされるの？とか忘れてしまいます。。。
なので、今回はちゃんと確認してみた！という記事になります。
node_moduleの中身を確認！
ということで、configの中身を確認してみました。 (すぐできるのに今まで怠っていました。。。)
version : "^1.30.0"
node_modules/config/lib/config.js
ここに記載されていました。
Application configurations are stored in files within the config directory of your application. The default configuration file is loaded, followed by files specific to the deployment type (development, testing, staging, production, etc.).
訳すと、
アプリケーション構成は、アプリケーションのconfigディレクトリ内のファイルに格納される。デフォルト設定ファイルが読み込まれ、続いて 特定の種類にファイル(development, testing, staging, productionなど)に固有のファイルによって異なる。
なるほど、ってことは、 「さきにdefault.jsonが読み込まれる」ってことだ。
なので、default.json → development.json みたいな順番で、 仮に同じ値(ネスト構成が同じ)があれば、上書きになるってことだ。
あー、すっきりしましたｗ
以上
【VR】仮想店舗(Virtual Store)！？ Oculus Goで考える #1
これまで過去の記事で、Oculus Goの開発環境(Unity)などを整えていきました。 Oculusのアセットをインポートして、コントローラーを追加し移動できるようにするところまで進めたかと思います。
今回の記事は考察よりの内容です！
以前から個人的に色んな方のVRのコンテンツを少々拝見させてもらっていました。
Oculus Goでまず試したい！おすすめアプリ・ゲーム特選 | Mogura VR - 国内外のVR/AR/MR最新情報
すごいですよね～！ VRChatとかVRの中で映画をみんなで観る鑑賞会とかが開かれていたり！
私は参加したことない(参加するのが怖いのでお誘いお待ちしておりますw)ので気になることがあるのですが、 充電とかフレームレートとか...
まあそんなことを思っていても、開発していかないと知見がたまらないので、
「仮想店舗 (Virtual Store)」を開発してみようと思います！
ECサイトあるからええやん！というご意見はさておき、 なんとなくわくわくするので個人的に開発してみようかな～。
Unity Asset Store
私は日頃Unity使わないので、初めてちゃんとあさってみたのですが、すごい沢山アセットがあるんだな～、 と今更ながら思いました。
一番驚いたのが、こちら！ WillHuangさんという方が作成したもの。
もう、すっごい綺麗ですね。。！！ 購入はしていませんが、このアセットはOculusに対応しているとのこと。 (グラボを積んでいるPCでないといけないみたいです！)
＄50か～、このクオリティなら十分に納得ができる。
が、ちょっと高いな～。
と、思っていたところ値段もクオリティもお手頃なアセットを発見した。
これも十分綺麗ですね！ ＄16くらい。これなら購入してもよさそうだと思って購入。
ちょっと購入前に気になったのが、棚に並んでいる商品。
サンプル動画を観る限り、けっこう色んな種類の商品オブジェクトがあるみたい。 VRでこの店舗に訪れて商品に近づくと、商品にオブジェクトに文字が書いてあるが、 それがどうやって映るんだろう、なんて考えました。
購入はクレカで即購入できちゃいます！
Unityにインポート
「おお！一気にそれらしい！」
是非店内を歩きたいということで、ビルド！！
「やったー！！歩けた！！」
「あれ？でも....」
実機で見るとわかるのですが、オブジェクトがけっこうかくついている。。。 フレームレートの問題なのか？
Oculus Goのリフレッシュレートは、60Hz 、72Hzでコンテンツにより変化するらしい。 なるほどー。
原因がまだわからないけど、おそらくそこらへんに問題がありそうです。 もしわかる方いあたら是非連絡お待ちしております。！
店舗が暗い問題
最初アセットをインポートしてビルドしたとき、店舗が暗かったのです。 これはどうもLightingの問題だったようです。
メニューWindow > Lighting > Settings
Realtime LightingのAuto Generateをチェックボックスを外して、
Generate Lightingに設定&押下でOK！
まとめ
次は、商品が取れて、商品単体でポップアップみたいに確認できるようにしようかな！ そのあと、サーバーとの通信方法を考えよう！
今回は考察ということで、仮想店舗について考えました。
現状、ECサイトのみで店舗がない会社とか、VRで仮想店舗なんかあると面白そうだよね！ 求められるというより、ワクワクを追っていきます！！
以上
過去記事>>
