20191028のAWSに関する記事は18件です。

投稿日：2019-10-28T23:58:29+09:00

AWS初心者が構築してみた①構成図作成

IAM...

駆け出しインフラエンジニアです。
前職は全く違う業種で、ITに関する知識ほぼ皆無でした。
歴は半年以上1年未満くらい。AWSはここ最近業務で触るようになった程度。

AWSを勉強し始めた理由

ここ最近AWSをよく触るようになったのと、誰も周りに詳しい人がいないため

Qiitaを書き始めた理由

・人に見せるというのを意識すればしっかり考えるかなと思ったため。
・いつもQiitaにお世話になっているから。
・趣味で良く記事を書いていたから

目的

自分で考え、手を動かし、AWSへの知識を深めること。

やること

AWS初心者でもできる簡単な構成を考え、作成していく。
※可能な限り無料で頑張る。これから先もずっと。
①構成を考える＆構成図作成
②VPC作成
③EC2インスタンス作成

前提条件

・AWSアカウント(無料枠含む)が作成済みとなっていること

①構成を考える＆構成図作成

構成を考える

まず、構成については以下とする。
もう少しだけ凝った構成にしようかと思ったが、それはまた別にやろう。となったので簡単にした。
・東京リージョンに作成
・AZ-aのみ使用
・VPC内にパブリックサブネット/プライベートサブネットを作成
・VPCは10.0.0.0/16、パブリックは10.0.1.0/24、プライベートは10.0.2.0/24とする。
・パブリックにWEBサーバ、プライべートにDBサーバ(EC2)を作成
・DBサーバに接続できるのはWEBサーバのみ
・冗長構成とはしない

構成図作成

自分で考えた構成を構成図として表す。
構成図かけるようになったら楽しいよね！っていうことで、どこで作れるのか色々調べたところ、
Draw.ioというサイトがよさそうだったのでこのサイトを使います。無料なので。
※上記URLからだと設定しなくてもAWSの図形を使用することができます。
※Draw.ioは物凄く便利なので覚えておいても損はないと思います。

簡単にですが使い方を記載します。
・初めに保存先を聞かれるので任意の場所へ。
・保存名聞かれるので適当に。
・図形は左ペインより選択する。GroupsとComputeは良く使う。
・図形の追加は左ペイン下にある[+More Shapes...]を選択すると
・jpeg等でエクスポートしたい場合は[File]->[Export as]を選択。
　※基本的に保存は.drawio形式でして、またいつでも編集できるようにしておく。

Draw.ioを使い今回構築していく構成は簡単に以下となる。

改めて見返すとセンス無いなっていうのが分かります。

構成図作成編はこれで終わり。次回②VPC作成編にて。

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T23:26:58+09:00

【CodeBuild】'NoneType' object has no attribute 'get'

エラーの内容

CodeBuildでCloudformationで使用するアーティファクトを作成しようとしたところ、以下のエラーが発生した。
'NoneType' object has no attribute 'get' 
原因

単純に、Cloudformationのテンプレートが間違っていると発生するエラーのようだ。
以下を参照

AttributeError: 'NoneType' object has no attribute 'items' on malformed CloudFormation

フォーラムでも叩かれているけどこのエラー文は本当にミスリーディングを引き起こすからやめてほしい・・・

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T23:10:33+09:00

S3に完全に同じファイルが上がってるか確認するロジックでちょっとハマったのでメモ。

いつもの如く、ブログからの転載です。
https://munchkins-diary.hatenablog.com/entry/2019/10/28/230924
最近あんまり書いてないですが、そろそろ再開したい。

S3上のファイルのチェックサムを取得する方法でハマりやすいとこと、下の方におまけでJavaでfileのチェックサムを計算する方法を書いておきました。

誰かの役に立てば幸いです。
(なおあまり)

S3のチェックサムを比較したい

数GBのファイルをS3に挙げるような処理を書いていて、後続処理の失敗などでリトライしたいというのがあった。

この場合、ファイルをアップロードし直すのはムダだが、移行元ストレージ内の対象ファイルが変更にされている可能性もある。
したがって、すでにS3上に完全に同じファイルがあるときだけアップロードをリトライしたい。

この場合、チェックサムを比較するのが楽なので、S3のgetObjectMetaData APIを利用して以下のようにコードを書いた。
 private boolean shouldSkip(String bucketName, String key, String md5CheckSum) {
      try {
        ObjectMetadata meta = s3Client.getObjectMetadata(bucketName, key);
        if (meta == null || meta.getContentMD5() == null) {
          log.info("meta data not exist for the file {} in bucket {}", key, bucketName);
          return false;
        }
        log.info(
            "Checksum of existing file is {} and present file checksum is {}",
            meta.getContentMD5(),
            md5CheckSum);
        return meta.getContentMD5().equals(md5CheckSum);
      } catch (SdkClientException e) {
        log.error("Exception thrown while validating the checksum of the file {}", key, e);
        return false;
      }
    }
しかし、どうもうまく行かない。
ObjectMetaData#contentMD5がどうしてもNullになってしまうのだ。

調べたところ、S3における既存オブジェクトのチェックサムはcontentMD5ではなく、Etagに付与されるらしい。

じゃあcontentMD5は何に使うかと言うと、更新時にHTTPヘッダに付与されて、S3内での改ざん確認（正しい使い方）に使うため、getでオブジェクトを取得する時は返されないのだとか。

したがって、S3から落として来たファイルのチェックサムを知りたい時はEtagと比較する必要がある。

こんな感じ。
    private boolean shouldSkip(String bucketName, String key, String md5CheckSum) {
      try {
        ObjectMetadata meta = this.s3Client.getObjectMetadata(bucketName, key);
        if (meta == null || meta.getETag() == null) {
          log.info("meta data not exist for the file {} in bucket {}", key, bucketName);
          return false;
        }
        log.info(
            "Checksum of existing file is {} and present file checksum is {}",
            meta.getETag(),
            md5CheckSum);
        return meta.getETag().equals(md5CheckSum);
      } catch (SdkClientException e) {
        log.error("Exception thrown while validating the checksum of the file {}", key, e);
        return false;
      }
    }
これならちゃんと動く。誰かの役に立てば幸いです。

おまけ Javaでのチェックサム確認方法

チェックサムでググって飛んで来た人のために一応書いておくと、Javaでチェックサムを計算する方法はこんな感じ。
  public static String checkMd5Checksum(File file) {
    try (BufferedInputStream is = new BufferedInputStream(new FileInputStream(file))) {
      return DigestUtils.md5Hex(is);
    } catch (Exception e) {
      // Not likely to occur.
      log.error(
          "ERROR Happened while calculating the check sum for file {}", file.getAbsolutePath(), e);
      return "NOT FOUND";
    }
  }
sha256なら DigestUtils#md5Hexを DigestUtils#sha256Hexに変えるだけ。

以上、メモでした。

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T22:41:23+09:00

【SRE】SRE業務1ヶ月で考えたこと

SRE業務についたよ

転職して、SREエンジニアとして働いています。
転職後、全く何をやっていいのかわからず、先輩に聞きながら進めていく中で、大方これをやっていく方針が決まったので、その内容を記載させていただきます。

システムを構築する上で常に意識すること

システムを考える上で、重要なことは以下3点だと考えています。

スケーラビリティ

負荷が増大したとしても、パフォーマンスを保つことができる機能のことを言います。
大量のトラフィックが来たときに、サーバーは過負荷状態になります。
この際に、サーバー自体が自動でサーバーを増やしてくれれば、トラフィックによるシステムの障害を防ぐことができます。

この設定を容易にしてくれるのが、Kubernetesです。
例えばKubernetesがスケールする方法には、スケールアウト(水平スケール)、スケールアップ(垂直スケール)の2種類あります。
対象としては、Pod、Nodeのスケール2つがあります。下記の記事が参考になります。
KubernetesのPodとNodeのAuto Scalingについて
 [超簡単！]kubernetesでオートスケール

冗長性

これはシステムの信頼性を担保するための性質です。
ここでは、主にデータベースの話になります。

Read Replicaの数をどうするか

例えば、AWS Auroraの場合、Read Replicaをいくつ設置するかというのははじめに考えることだと思います。
よくあるのは、Read Replicaを異なるリージョンごとに設定(MZで設定)することです。

バックアップ

毎日バックアップされてれば基本的に問題ないと思っています。
例えば、AWS Auroraだと、自動的にバックアップを行ってくれます。
AWS Auroraは毎日スナップショットが保存され、そこから復元を行うことができます。

保存期間を何日に設定すべきか？(現状1日で設定)

バックアップする頻度の問題になると思います。
クラッシュした時の発生頻度、発生回数を考慮します。
つまり、発生可能性に対して判断するのです。

冗長を考えるときに重要となる質問
- サーバー1台死ぬ可能性は？
- マルチリージョンにしてて、一つのリージョンが死ぬ可能性
　以前のAWSの障害の場合どうするか？⇛年間0.1%が発生可能性
- Masterが詰まって機能しなくなるケースはどうする？
- データが失われて、バックアップを使用しなくてはいけない可能性はどのくらいあるか？
- どのくらい過去にさかのぼってデータ復旧をしなければいけないのか

運用性

ここには2つ意味が含まれています。

1. 新しい開発メンバーに対して優しい情報の残し方
ドキュメントなどを定期的に残しており、キャッチアップするのに図やドキュメントをみるだけで実施することができるのがベストだと思ってます。

2. 学習コストの低下
新しいエンジニアが見てもわかりやすく、学習コストが低いインフラ構成を指します。

コンテナ基盤構築

Kubernetesベースで書きたいと思います。

Kubernetes 参考記事

コンテナ基盤構築に関しては、Kubernetesをいかに理解するかが重要になると思っています。ここではKubernetesで重要となる記事を紹介させていただきます。
Kubernetes: スケジューラの動作


クラスタの構成

主に2種類あると考えています。

ゾーンクラスタ

ゾーンクラスタ

デフォルトの設定で作成すると、一つのリージョン、ゾーン内にクラスタが作成されます。

マルチゾーンクラスタ

1 つのリージョンに単一のクラスタマスターを作成し、複数のゾーンにノードを作成する方法です。
ゾーンをそれぞれ分けるだけなので、簡単に構築することができます。

リージョナルクラスタ

3 つのゾーンに 3 つのクラスタマスターを作成する方法です。
デフォルトで3 つのゾーンにノードを作成します。
小さいサービスだと、少しノードの数が多すぎるかもしれません。

参考記事

GKE multi-cluster Ingress
本番環境での Google Kubernetes Engine の準備
 リージョンクラスタ
 GKEのRegional Clusters(Beta)を試してみた

Nodeをいくつに設定するべきか

はじめにぶつかるところだと思います。
etcdのRaftアルゴリズムの性質上、3, 5, 7の奇数のnode数が推奨されています。
詳しくは、下記を確認してみてください。

なぜnodeが3個以上必要か

下記が参考になりました。
https://qiita.com/ntoreg/items/ec6f1eca87ba5c5c0399
https://www.techscore.com/blog/2019/03/28/raft-consensus-algorithm/

ReplicaSetの数をいくつにすべきか

Podの数を随時いくつに保つべきか決定するとことです。
下記の式で数を算出するこができますが、これは実際にサービスを構築してから決める方法です。

必要なレプリカ数 = ceil(sum(Podの現在のCPU使用率) / targetAvrageUtilazation)

参考本：
Kubernetes完全ガイド

CI/CDパイプライン構築

ここではデプロイ自動化に焦点を当ててみます。

大事にすべき観点

自動化

人の手を介入させない

高速化

デプロイは速いほうがよい。ビルドとか時間かかるのは嫌

属人性の排除

誰でもデプロイできる

最初のデプロイ自動化に関しては、高度なデプロイ方法(グリーンデプロイなど)は考えなくて良いと思っています。理由は、あとで差し替えることが可能で、高度なデプロイ方法には学習コストがかかるので時間がないときは考えなくても良いと考えました。ただ後々取り入れることを前提にしておけばよいと思います。

Kubernetes デプロイ方法

今回は、Kubernetesを使ったデプロイ方法に焦点を絞っていきたいと思います。

Spinnaker

NetFlixが開発しています。

Pros
・高度なデプロイに適している
　・マルチクラウドへのデプロイ
　　https://tech.plaid.co.jp/builderscon-2018/
　・カナリアデプロイ
　・Blue-Greenデプロイ
Cons
　・学習コストがかかる

高度なデプロイに関する参考記事

https://clonos.jp/knowledge/detail14/
https://garafu.blogspot.com/2018/11/release-strategy.html

Skaffold

Pros
・googleが作っているので、信用できる
・イメージのタグを自動で付与する機能がある
Cons
・buildが遅いらしい....
・ローカルにkubernetesの設定が必要になる
・kubernetesの知識が必要になる

参考記事

https://qiita.com/tomoyamachi/items/660bd7bb3afff8340307
https://www.publickey1.jp/blog/18/googlekubernetesskaffoldkubernetesminikube.html

GitOps

Pros
・導入が容易そう
・kubernetesの知識が不要
Cons
・Githubが落ちたらなんにもできなくなる

何を用いるか

GitOpsを実現するツールは非常に増えつつあります。
CloudBuild, ArgoCD, Fluxなど様々です。

参考記事

https://cloud.google.com/kubernetes-engine/docs/tutorials/gitops-cloud-build?hl=ja

Gitopsの例

k8s用リポジトリとアプリケーション用リポジトリ(Go)を分ける(2つ作成)
ステージングへのデプロイ
①開発者コミット
②Circle CIでテストまわす
③Circle CIをトリガーにCloud Buildを動かす
　・ビルドしたイメージをCloud Registoryにpush
　・同時にk8s用のリポジトリにpush
④GKEのクラスターへpush

プロダクションのデプロイ
以下上記ステージング④からの続き
　①上記③で作成されたk8s用のPRをマージする⇛CloudBuild動く
　②GKEのクラスターへpush　

メモ
　・mergeされたタイミングでステージングは、自動deploy
　・プロダクション環境へのdeploy
　　・k8s用のリポジトリにproduction用のリポジトリを作成
　　・stagingがdeployされれば、stagingとproductionでPRを作成
　　　⇛このPRがマージされれば、production環境も自動deploy
　その他
　　・ステージング環境への自動deployのタイミングでエラーが起きたらどうするか？
　　　⇛前のコミットに戻す？　⇛　revertでPR作ってdeploy　⇛　これで検証
　　　　⇛goのリポジトリ、k8sのリポジトリをどのように戻す？
　　　　　⇛ここらへんは動かして検証していく必要がある
　　・プロダクション環境でエラーが出たときはどうする？
　　　⇛revertでPR作ってdeploy　⇛　これで検証
　　　⇛動く環境に戻す
　　　　⇛どう戻すか？
　　　　　⇛上記と同様
　　　⇛修正は、ブランチ戦略同様、hotfixブランチを切り対応

デプロイに関して追加で考慮すべきこと

masterにマージする前に、デプロイしたい場合があること

PRをマージすることでデプロイすることが正解ではない

Circle CIを使うのが正解ではない

Githubが落ちた時にきちんとワークする？

Githubが落ちた時にステージング環境にdeployできるか

手動をあえて残す方法を検討する

マージはしたいけど、deployしたくないの場合どうする

ブランチ単位のdeployしたいときどうする

監視

監視で重要なこと

どのくらいの粒度でアラートを出すべきかアラート疲れを起こさせないために、適切な粒度でアラートを管理する必要がある Kubernetesの監視となるとよく上がるのがこの2つだった

どこを監視するのか

アラートを出してからどのような手順で原因までたどり着くか

どこで何を監視するか

何を

HTTPレスポンスコード、リクエスト時間(レイテンシ)が有効らしい(入門監視より)

どこで

ユーザーに一番近いところ。CloudFrontとかが該当する(入門監視より)

データ収集

なんのデータを集めて、監視をするのかという話です。
主に2つあります。

メトリクス

メトリクスの取得頻度は60秒に一回が推奨されています(入門監視より)

ログ

例えば、GCPだとStack Driverにログがはかれており、AWSだとS3かCloudWatchです。

slack通知(アラート疲れさせないために)

重要なエラーが起きた時はslackで通知されるようにします。
ここで重要なのが、アラートの粒度とメンバーが見なければいけないと思わせるチャネルに設計するか**だと思っています。
アラートが多すぎると、段々見なくなってくるし、かといってアラートが少なすぎて重要なことを通知してくれないのも困ります。ココらへんは運用しながら設計していくしか無いと考えています。

ダウンタイム

システムがダウンしてもよい時間を探ります。
ただ最初のサービスだと、最初の小さいチームだと、ダウンの気づかなくて、決めた時間をすぎる可能性のほうが高いのではないでしょうか。
なので、最初はダウンタイムの時間を設定するよりも「どのようにアラートを出すか」を設計するほうが重要

許容できるダウンタイムを決める記事は下記が参考になります。
https://dev.classmethod.jp/cloud/aws/decision-method-for-aurora-multiaz/

この記事では、最初に「(サービスなどが停止・中断している時間)が10分を許容できるか？」という質問をしていき、冗長性をどう設計するか決めていきます。
※今回は、「アラートの設計」が重視されると思ったので、監視の項目に記載しています。

例：
(サービスなどが停止・中断している時間)が10分を許容できるか？　⇛　できない
「1, 2分だったら？」　⇛　許容できる

実際ダウンタイムの時間が10分というのはかなり短く、
この問いかけは、深夜体制のチーム体制ができている、もしくはそのチーム体制を築くことができる会社だと思っています。

監視ツール

Kubernetesの監視ツールについて見ていきます。

Push型とPull型

Push型、Pull型の監視システムについて⇛時代の流れは、Pull 型から Push 型？
http://yasuharu519.hatenablog.com/entry/2017/12/16/215855

Datadog

Datadogについてよくまとまってる
https://www.datadoghq.com/ja/blog/monitoring-kubernetes-datadog/

Pros
・Cloud WatchとGKEの統合が容易そう
　AWS CloudWatchの情報や、NewRelicなどの他のMonitoring Toolの情報などを簡単な設定でDatadogに取り込む事ができる。この機能を用いることでDashboardの情報をDatadogに一元化することが可能になる。
・設定(インストールなど)が容易⇛GUIで可能
・Slackとの連携が簡単
・時代の流れに関してPush型なので、こっち使いたいw

Cons
・お金かかる⇛ミニマム月3000円くらい(ログとインフラ)
・監視対象が増えた時に監視サーバに負荷が集中しがち
　⇛現状サーバーの台数が多いというわけではないので、Consとしては弱い
・今後APM(Application Performance Monitoring)の監視をしていくとなると料金が倍になる

Prometheus

Pros
・無料

Cons
・設定(インストールなど)がDatadogよりも面倒
・Cloud WatchとGKEの統合の方法が現状わからない
・AutoScaling 等で監視対象の数が変わった場合、監視対象リストをアップデートする必要がある
。これ面倒

参考記事

http://yasuharu519.hatenablog.com/entry/2017/12/16/215855
https://techblog.zozo.com/entry/monitoring-kubernetes-using-datadog
https://tech.willgate.co.jp/entry/2019/03/26/120553

可搬性の高いコンテナの設計

開発環境で docker-composeコマンド1発で環境構築ができ、migration、seedの管理もできており、ステージング環境やプロダクション環境のimageがほしければすぐに持ってくることができる状態がベストだと思っています。
難しい言葉でいうと、
「immutableかつdisposable」　⇛　不変でかつ使い捨てできる

参考記事
　https://www.publickey1.jp/blog/14/immutable_infrastructure_1.html
　https://mizzy.org/blog/2016/04/22/1/
　http://simplearchitect.hatenablog.com/entry/2016/02/18/165917

インフラのコード化

なぜIaCとCaCを区別したほうがよいか

運用する面でこの考え方のほうが便利で、
同じにしてし考えてしまうと、インフラ構築用のコードをからコードを実行することになるため。

なぜIaS(インフラのコード化)なのか

そもそもの考え方として以下2つがある。
・クラウドのインフラをどのように作ったかをコードベースで残すため
・同じ環境terraformのコマンドを実行すればすぐに作成できる状況を作るため

IaC(Infrastructure As Code)

サーバーの構築

主に使用されるツール

Terraform

Cloud Formation

CaC(Configuration As Code)

各種のツールやライブラリをインストールする
①terraformでフォルダを分けて管理
　terraformで管理すると、間違って構築のフォルダを実行してしまう可能性がある？
②別のツールで実行
　Puppet、Chef、Salt、Ansible
　⇛学習コストを考慮するとAnsible
https://cloud.google.com/solutions/google-compute-engine-management-puppet-chef-salt-ansible-appendix?hl=ja

権限設定

なぜ権限設定をしなければいけないかというと、事故一番恐ろしく、起きやすいのが人為的ミスだと思っています。これをそもそも発生しにくくするために、適切な人に適切な権限を付与しましょう。
GCPだとIAMで設定できるので、必ず設定しましょう。
　　

その他

クラウドのセキュリティの調査・検証

復旧手順の再現

データの復元化手順をドキュメントに残し、検証する
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.html　　

インシデント発生時の対応のドキュメント化

カオスエンジニアリング

本番サーバーにわざと障害を起こすクレイジーな方法。
近々やってみる。
Netflix
https://qiita.com/naokiiiii/items/de20997a70922c01f754

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T22:41:23+09:00

【SRE】SRE業務1ヶ月で考えたことをまとめてみた

SRE業務についたよ

転職して、SREエンジニアとして働いています。
転職後、全く何をやっていいのかわからず、先輩に色々聞きながら進めていく中で、概要だけ記載するところが欲しかったので、記載していきます。
またこの記事は随時アップデートしていく予定です。

システムを構築する上で常に意識すること

システムを考える上で、重要なことは以下3点だと考えています。

スケーラビリティ

負荷が増大したとしても、パフォーマンスを保つことができる機能のことを言います。
大量のトラフィックが来たときに、サーバーは過負荷状態になります。
この際に、サーバー自体が自動でサーバーを増やしてくれれば、トラフィックによるシステムの障害を防ぐことができます。

この設定を容易にしてくれるのが、Kubernetesです。
例えばKubernetesがスケールする方法には、スケールアウト(水平スケール)、スケールアップ(垂直スケール)の2種類あります。
対象としては、Pod、Nodeのスケール2つがあります。下記の記事が参考になります。
KubernetesのPodとNodeのAuto Scalingについて
 [超簡単！]kubernetesでオートスケール

冗長性

これはシステムの信頼性を担保するための性質です。
ここでは、主にデータベースの話になります。

データベースの配置

例えば、AWS Auroraの場合、Read Repliaをいくつ、どのように設置するかというのははじめに考えることだと思います。よくあるのは、Read Replicaを異なるリージョンごとに設定(MZで設定)することだと思います。
TODO: またS3とかにもこの冗長性は適応できるので、そこも考える必要がある

バックアップ

毎日バックアップされてれば基本的に問題ないと思っています。
例えば、AWS Auroraだと、自動的にバックアップを行ってくれます。
AWS Auroraは毎日スナップショットが保存され、そこから復元を行うことができます。

その他冗長性を考えるときに重要となった質問

サーバー1台死ぬ可能性はあるか

マルチリージョンにしてて、一つのリージョンが死ぬ可能性はあるか　以前のAWSの障害の場合どうするか？⇛年間0.1%が発生可能性

Masterが詰まって機能しなくなるケースはどうする

データが失われて、バックアップを使用しなくてはいけない可能性はどのくらいあるか

どのくらい過去にさかのぼってデータ復旧をしなければいけないか

メンテナンス性

ここには2つ意味が含まれています。

単純性

1. 新しい開発メンバーに対して優しい情報の残し方
ドキュメントなどを定期的に残しており、キャッチアップするのに図やドキュメントをみるだけで実施することができるのがベストだと思ってます。

2. 学習コストの低下
新しいエンジニアが見てもわかりやすく、学習コストが低いインフラ構成を指します。

運用性

他のメンバーが運用しやすいようにしましょう！！

コンテナ基盤構築

Kubernetesベースで書きたいと思います。

Kubernetes 参考記事

コンテナ基盤構築に関しては、Kubernetesをいかに理解するかが重要になると思っています。ここではKubernetesで重要となる記事を紹介させていただきます。
TODO: 参考記事アップデートする
Kubernetes: スケジューラの動作

クラスタの構成

主に2種類あると考えています。

ゾーンクラスタ

ゾーンクラスタ

デフォルトの設定で作成すると、一つのリージョン、ゾーン内にクラスタが作成されます。

マルチゾーンクラスタ

1 つのリージョンに単一のクラスタマスターを作成し、複数のゾーンにノードを作成する方法です。
ゾーンをそれぞれ分けるだけなので、簡単に構築することができます。

リージョナルクラスタ

3 つのゾーンに 3 つのクラスタマスターを作成する方法です。
デフォルトで3 つのゾーンにノードを作成します。
小さいサービスだと、少しノードの数が多すぎるかもしれません。

GKE multi-cluster Ingress
本番環境での Google Kubernetes Engine の準備
 リージョンクラスタ
 GKEのRegional Clusters(Beta)を試してみた

Nodeをいくつに設定するべきか

はじめにぶつかるところだと思います。
etcdのRaftアルゴリズムの性質上、3, 5, 7の奇数のnode数が推奨されています。
詳しくは、下記を確認してみてください。

なぜnodeが3個以上必要か

下記が参考になりました。
https://qiita.com/ntoreg/items/ec6f1eca87ba5c5c0399
https://www.techscore.com/blog/2019/03/28/raft-consensus-algorithm/

ReplicaSet数をいくつに設定すべきか

Podの数を随時いくつに保つべきか決定するとことです。
下記の式で数を算出するこができますが、これは実際にサービスを運用もしくは負荷試験をしてから決定する方法です。

必要なレプリカ数 = ceil(sum(Podの現在のCPU使用率) / targetAvrageUtilazation)

参考本：
Kubernetes完全ガイド

CI/CDパイプライン構築

観点

自動化

人の手を介入させない

高速化

デプロイは速いほうがよい。ビルドとか時間かかるのは嫌

属人性の排除

誰でもデプロイできる

最初のデプロイ自動化に関しては、高度なデプロイ方法(グリーンデプロイなど)は考えませんでした。
理由は、あとで差し替えることが可能で、高度なデプロイ方法には学習コストがかかると考えたからです。
ただ後々取り入れることを前提にしておけばよいと思います。

Kubernetesでのデプロイ方法

今回は、Kubernetesを使ったデプロイ方法に焦点を絞っていきたいと思います。

CirrcleCIでのデプロイ

使用している企業さんが一番多い気がします。
CI回して、そこからデプロイもしてしまえば良いですね。

Spinnaker

Spinnaker

NetFlixが開発しており、高度なデプロイに適しているしています。
高度なデプロイとは、マルチクラウドへのデプロイ、カナリアデプロイ、Blue-Greenデプロイのようなデプロイ方法を指します。
ただデメリットとして、学習コストがかかることはよく挙げられます。

PLAID Engineer BlogHOMEPLAIDエンジニア募集中！PLOG SRE Netflix発のOSS"Spinnaker"でマルチクラウドにデプロイしている話 #builderscon
近年のデプロイ手法について
 デプロイ / リリース手法まとめ

Skaffold

Skaffold

Pros
・Googleが作っているので、信用できる
・イメージのタグを自動で付与する機能がある..らしい

Cons
・buildが遅いらしい....
・ローカルにkubernetesの設定が必要になる
・kubernetesの知識が必要になる

Kubernetesの開発環境で困っているならskaffoldを使え
 Google、開発者のためのKubernetes用コマンドラインツール「Skaffold」オープンソースで公開

GitOps

Githubのソースコードを正とし、Githubを中心にCI/CDを回していきましょうという考え方です。

Pros
・導入が容易そう
・なんか流行ってる

Cons
・Githubが落ちたらなんにもできなくなる

何を用いるか

GitOpsを実現するツールは非常に増えつつあります。
ArgoCD, Fluxなどが有名です。

Cloud Build を使用した GitOps スタイルの継続的デリバリー
 【ArgoCD/GKE】GitOpsを実現させる
 Argo CDによってGKEでGitOpsをする

デプロイに関して考慮したこと

masterにマージする前に、デプロイしたい場合があること

PRをマージすることでデプロイすることが正解ではない

Circle CIを使うのが正解ではない

Githubが落ちた時にきちんとワークするか、デプロイできるか

手動をあえて残す方法を検討すべきか

マージはしたいけど、deployしたくない場合どうするか

ブランチ単位のdeployしたいときどうする

監視

監視で重要なこと

どのくらいの粒度でアラートを出すべきかアラート疲れを起こさせないために、適切な粒度でアラートを管理する必要がある Kubernetesの監視となるとよく上がるのがこの2つだった

どこを監視するのか

アラートを出してからどのような手順で原因までたどり着くか

どこで何を監視するか

何を

HTTPレスポンスコード、リクエスト時間(レイテンシ)が有効らしい(入門監視より)

どこで

ユーザーに一番近いところ。CloudFrontとかが該当する(入門監視より)

データ収集

なんのデータを集めて、監視をするのかという話です。
主に2つあります。

メトリクス

メトリクスの取得頻度は60秒に一回が推奨されています(入門監視より)

ログ

例えば、GCPだとStack Driverにログがはかれており、AWSだとS3かCloudWatchです。

slack通知

重要なエラーが起きた時はslackで通知されるようにします。
まずは検知することが大事。
そして追加で重要なことが、アラートの粒度になります。
アラートが多すぎると、段々見なくなってくるし、かといってアラートが少なすぎて重要なことを通知してくれないのも困ります。つまりメンバーがいつまでも関心を保ってくれるチャンネル設計をしましょうということになります。
ココらへんは現在試行錯誤中です。

ダウンタイム

システムがダウンしてもよい時間を探ります。
ただ最初のサービスだと、最初の小さいチームだと、ダウンの気づかなくて、決めた時間をすぎる可能性のほうが高いのではないでしょうか。そのため、最初はダウンタイムの時間を設定するよりも「どのようにアラートを出すか」を設計するほうが重要だと考えました。

許容できるダウンタイムを決める記事は下記が参考になります。
ちょっと待って！Auroraを使う時にMulti-AZが本当に必要ですか？

この記事では、最初に「(サービスなどが停止・中断している時間)が10分を許容できるか？」という質問をしていき、冗長性をどう設計するか決めていきます。
※今回は、「アラートの設計」が重視されると思ったので、監視の項目に記載しています。

ただ、実際ダウンタイムの時間が10分というのはかなり短く、
この問いかけは、深夜体制のチーム体制ができている、もしくはそのチーム体制を築くことができる会社だと思っています。

監視ツール

Kubernetesの監視ツールについて見ていきます。

Push型とPull型

Push型、Pull型の監視システムについて⇛時代の流れは、Pull 型から Push 型？

Datadog

Datadogについてよくまとまってる
モニタリングシステムの Push 型 Pull 型アプローチと Prometheus についての考察

Pros
・Cloud WatchとGKEの統合が容易
　AWS CloudWatchの情報や、NewRelicなどの他のMonitoring Toolの情報などを簡単な設定でDatadogに取り込む事ができる。この機能を用いることでDashboardの情報をDatadogに一元化することが可能になる。
・設定(インストールなど)が容易⇛GUIで可能
・時代の流れに関してPush型なので、こっち使いたい...
・UIが綺麗.....

Cons
・お金かかる⇛ミニマム月1万円くらい
・監視対象が増えた時に監視サーバに負荷が集中しがち
　⇛現状サーバーの台数が多いというわけではないので、Consとしては弱い
・今後APM(Application Performance Monitoring)の監視をしていくとなると料金が倍になる

Prometheus

Pros
・無料

Cons
・設定(インストールなど)がDatadogよりも面倒
・Cloud WatchとGKEの統合の方法が現状わからない
・AutoScaling 等で監視対象の数が変わった場合、監視対象リストをアップデートする必要がある
。これ面倒

モニタリングシステムの Push 型 Pull 型アプローチと Prometheus についての考察
 クラウド時代の監視ツールDatadogをあらためて紹介します
 【運用監視ツール比較】ZABBIXからPrometheusへの移行を開始しました

可搬性の高いコンテナの設計

開発環境で docker-composeコマンド1発で環境構築ができ、migration、seedの管理もできており、ステージング環境やプロダクション環境のimageがほしければすぐに持ってくることができる状態がベストだと思っています。
難しい言葉でいうと、「immutableかつdisposable」　⇛　不変でかつ使い捨てできる

Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく

インフラのコード化

なぜIaCとCaCを区別したほうがよいか

運用する面でこの考え方のほうが便利で、
同じにしてし考えてしまうと、インフラ構築用のコードをからコードを実行することになるため。

なぜIaS(インフラのコード化)なのか

そもそもの考え方として以下2つがある。
・クラウドのインフラをどのように作ったかをコードベースで残すため
・同じ環境terraformのコマンドを実行すればすぐに作成できる状況を作るため

IaC(Infrastructure As Code)

サーバーの構築

主に使用されるツール

Terraform

Cloud Formation

CaC(Configuration As Code)

各種のツールやライブラリをインストールする
①terraformでフォルダを分けて管理
　terraformで管理すると、間違って構築のフォルダを実行してしまう可能性がある？
②別のツールで実行
　Puppet、Chef、Salt、Ansible
　⇛学習コストを考慮するとAnsible

Infrastructure as Code 再考
 私は Infrastructure as Code をわかっていなかった
 Puppet、Chef、Salt、Ansible を使用した Compute Engine の管理 - 付録

権限設定

当たり前ですが、権限設定をしないと、人為的ミスが起きやすくなってしまいます。
この事故が一番恐ろしく、そして確率的に一番起きやすです。
これをそもそも発生しにくくするために、適切な人に適切な権限を付与しましょう、というのが第一歩だと思います。

随時更新していきます！！！
　　

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T22:21:32+09:00

リモートのpython3(psycopg2)からubuntu16.04@AWSのpostgresqlに接続

前提

①ubuntu16.04をAWS上で立ち上げpython3,postgresqlをインストール完了

②python3でpsyopg2が扱える

以下はSelectクエリの実行例です。リモートで実行する前にローカルで問題なく実行できることを確認しておきます。
#################################
###    Selectクエリの実行例    ###
#################################
import psycopg2, psycopg2.extras

# 1. Postgesqlの接続設定(設定に合わせて修正してください)
#HOST     = "localhost  #ローカルで実行するとき
HOST     = "172.0.0.1"  
PORT     = "5432"
DBNAME   = "postgres"
USER     = "postgres"
PASSWORD = "p@ssword"
CREDENTIAL = "host={h} port={p} dbname={db} user={u} password={pa}"\
    .format(h=HOST,p=PORT,db=DBNAME,u=USER,pa=PASSWORD)

QUERY = "Select * from exercise"　#テーブル名は任意に設定してください


# 2. Postgresに接続してクエリを実行
with psycopg2.connect(CREDENTIAL) as conn:
    with conn.cursor(cursor_factory=psycopg2.extras.DictCursor) as cur:

        # クエリ実行
        cur.execute(QUERY) 
        rows = cur.fetchall()

# 3. 結果を表示
print(rows[0])
やったこと

①セキュリティグループの設定(下図の赤枠の設定)

※「0.0.0.0/0」はすべてのリモートアクセスを許可しているので注意してください。

セキュリティグループの設定をする前にリモート接続を実行すると以下の通りTimeoutエラーが出ました。
OperationalError: could not connect to server: Connection timed out (0x0000274C/10060)
    Is the server running on host "3.113.15.235" and accepting
    TCP/IP connections on port 5432?
セキュリティグループの設定にPostgresqlを追加すると以下のRefusedエラーに代わりました。これでTCPの設定はOKです。
OperationalError: could not connect to server: Connection refused (0x0000274D/10061)
    Is the server running on host "3.113.15.236" and accepting
    TCP/IP connections on port 5432?
②postgresqlの設定ファイルの修正とpostgresqlの再起動

ph_hba.conf と　postgresql.confのファイルを修正します。そして修正後にpostgesqlを再起動するのですが以下のブログの最後の方で詳しく説明されていますのでこちらを参考ください。
https://qiita.com/ibara1454/items/40ce2d82926f48cf02bc

以上で終了です。ここまでの設定をすれば接続してクエリがリモートから実行できました。

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T21:49:29+09:00

AWSでCI・CD環境を構築

AWSでCI・CD環境を構築したはなし

こんにちは
今回はAWSのサービスを利用して、CI・CD環境を整えることについて書きたいと思います。
というのも、最近CI・CD環境をAWSのサービスのみで構築したので、備忘録もかねてとなります。

今回利用していくサービスは

CodePipeline

CodeBuild

CodeDeploy

となります。
CodeCommitも利用したら完璧でしたが、今回はGitHubでやりましたので、その手順で書きたいと思います。

手順

今回は、GitHubで管理されている、ソースを、テスト、ビルドして、EC2上にデプロイするというものをサクッと環境構築したいと思います。

先ずは、GitHubのリポジトリに適当にデプロイするソースをコミットします。（省略します。）

今回はmasterブランチでやろうと思いますが、GitHubの特定のブランチを選択することができますので、選択の幅はかなり広いかなと思いました。

続いて、CodePipelineの準備をしていきます。
パイプラインの作成を選択することで、GUIのコンソールから作成することができました。

SourceのステージでGitHub WebHookとの連携をします。（これも簡単にできます。）

次にBuildステージの設定ですが、今回はCodeBuildを利用しますので、デプロイするリポジトリのルートディレクトリにbuildspac.ymlをコミットする必要があります。
下記はサンプルです。
version: 0.2

run-as: root

phases:
  build:
    commands:
      - ここでテストやビルドのコマンドを記述してください
artifacts:
  files:
    - '**/*'
ビルドグループは適宜作成。
コンソールのアーティファクト(artifact)の部分でSourceステージで同期したものを選択します。
私の場合は、CodeBuildで提供されているDockerのイメージを利用しましたが、自分で作成したDockerイメージでも動かすことができるみたいです。（おそらくECRとかでイメージの保存をする感じになると思います。）

このとき出力アーティファクトはS3とかに保存しておくと良いかと思います。

最後にデプロイですが、今回はCodeDeployを利用するため、デプロイするリポジトリのルートディレクトリにappspac.ymlをコミットする必要があります。
下記はサンプルです。
version: 0.0
os: linux
files:
  - source: /
    destination: /var/src
hooks:
  BeforeInstall:
    - location: code_deploy/before_install.sh
      timeout: 300
      runas: root
  AfterInstall:
    - location: code_deploy/after_install.sh
      timeout: 300
      runas: root
上記の場合、対象のソースを/var/src配下に展開します。
また、デプロイ前とデプロイ語にshellを実行することが可能なため、配置後の権限だったりを変更することが可能となっています。

デプロイグループは適宜作成
今回はCodePipelineからのキックとなるため、対象のソースはCodeBuildで作成した、出力アーティファクトのものを選択します。

こんな感じで、AWSのサービスだけでもCI・CD環境を構築することができました。

最後に

今回はJenkinsやCircleCIを利用した方法ではなく、AWSのサービスのみでの構築について簡単に書いてみました。
AWSだけで行うメリットは、コスト管理だと思います。
他のサービスを利用すると、コスト管理が煩雑になったり、思わぬところでコストがかかったりします。
また、AWSのサービスですので、連携性はかなり良いし簡単に構築できるのもメリットかなと思いました。
また、CodeBuildは従量課金制なので、これも使いやすいかなと思いました。
余談ですが、先日Japan IT Weekに参加してきまして、とある方が、CI・CD環境の重要性について語っていました。
現在の開発はスピーディーに開発し、サイクルを早く回すことが重要となってくると思うので、CI・CDを自動化することは大切だと痛感しました。

では、今回はこのへんで。

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T18:34:23+09:00

AWS 異なるアカウントのセキュリティグループを使う

AWSアカウントをまたいだ VPC Peering 接続手順

VPCで「ピアリング接続」設定

レンジーが重なる場合、新規VPC作成例
VPC CIDR 172.23.0.0/16
セグメントB-1 172.23.252.0/24
セグメントB-2 172.23.253.0/24
セキュリティグループのインバウンドのソースに登録

AWSアカウントID/SGのID
659692xxxxxx/sg-c73axxxx
参考

VPCで「ピアリング接続」設定
http://yoshidashingo.hatenablog.com/entry/2014/03/28/141024

[VPC Peering] 異なるAWSアカウントでのVPCピア接続を試してみた
https://dev.classmethod.jp/cloud/aws/vpc-peering-different-awsaccount/

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T18:05:35+09:00

AWS SystemsManager の SessionManager で SSH ログインだけ有効にする IAM ポリシー

SessionManagerは踏み台不要でサーバに入り、 CLI できる便利なツールですよね。
SSH不要時代がくるか!?AWS Systems Manager セッションマネージャーがリリースされました!

しかしながら、以下のような辛みがありました。

パスワードなしでsudoできるssm-userでしかログインできない

ブラウザからしか入れないので、 switch role したらセッション切れる

2つめの辛みは、SSH/SCP が使えるようになったことで解消されました！
AWS Systems Manager セッションマネージャーでSSH・SCPできるようになりました

そうした時に、1つめの辛みである ssm-user でのログインを禁止したくなったので、IAM ポリシーを書いてみました。以下に示します。
キモは ssm:SessionDocumentAccessCheck という Condition です。

公式ドキュメントを見てこの Condition を見つけたので、あとはドキュメントを読んでみてください。
※例示されているポリシーは GetDocument の Statement に ssm:SessionDocumentAccessCheck の Condition が記述されていますが、これは間違いだと思います。マネジメントコンソールのビジュアルエディターで警告出たので。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/getting-started-restrict-access-quickstart.html
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ssm:StartSession",
            "Resource": [
                "arn:aws:ssm:*:*:document/AWS-StartSSHSession",
                "arn:aws:ec2:*:*:instance/*"
            ],
            "Condition": {
                "BoolIfExists": {
                    "ssm:SessionDocumentAccessCheck": "true"
                }
            }
        },
        {
            "Effect": "Deny",
            "Action": "ssm:GetDocument",
            "Resource": "arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:GetConnectionStatus",
                "ec2:DescribeInstances",
                "ssm:DescribeSessions",
                "ssm:DescribeInstanceProperties"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "ssm:TerminateSession",
            "Resource": "arn:aws:ssm:*:*:session/*"
        }
    ]
}

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T18:05:35+09:00

AWS SessionManager で SSH だけを有効にするIAMポリシー

SessionManagerは踏み台不要でサーバに入り、 CLI で操作できる便利なツールですよね。
SSH不要時代がくるか!?AWS Systems Manager セッションマネージャーがリリースされました!

しかしながら、以下のような辛みがありました。

パスワードなしでsudoできるssm-userでしかログインできない

ブラウザからしか入れないので、 switch role したらセッション切れる

2つめの辛みは、SSH/SCP が使えるようになったことで解消されました！
AWS Systems Manager セッションマネージャーでSSH・SCPできるようになりました

そうした時に、1つめの辛みである ssm-user でのログインを禁止したくなったので、IAM ポリシーを書いてみました。以下に示します。
キモは2つ。

ssm:SessionDocumentAccessCheck という Condition

SSM-SessionManagerRunShell の ssm:GetDoument を Deny

公式ドキュメントを見てこの Condition を見つけたので、あとはドキュメントを読んでみてください。
※例示されているポリシーは GetDocument の Statement に ssm:SessionDocumentAccessCheck の Condition が記述されていますが、これは間違いだと思います。マネジメントコンソールのビジュアルエディターで警告出たので。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/getting-started-restrict-access-quickstart.html
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ssm:StartSession",
            "Resource": [
                "arn:aws:ssm:*:*:document/AWS-StartSSHSession",
                "arn:aws:ec2:*:*:instance/*"
            ],
            "Condition": {
                "BoolIfExists": {
                    "ssm:SessionDocumentAccessCheck": "true"
                }
            }
        },
        {
            "Effect": "Deny",
            "Action": "ssm:GetDocument",
            "Resource": "arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:GetConnectionStatus",
                "ec2:DescribeInstances",
                "ssm:DescribeSessions",
                "ssm:DescribeInstanceProperties"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "ssm:TerminateSession",
            "Resource": "arn:aws:ssm:*:*:session/*"
        }
    ]
}

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T14:32:00+09:00

【AWS】ALB->ドメイン->SSL証明書メモ

概要

AWSでインフラ構築する一部分のメモ
実際にどういう構成で構築するのか次第で柔軟に参考にして頂ければ幸いです。

最終的にできる構成

今回出来上がる構成は以下の通りです

Request(https) -> Route53 -> ALB -> EC2

構築の流れ

※前提：「EC2インスタンス有」「ドメイン取得済み(今回はfreenom)」「セキュリティグループ有」

Route53設定 (ネームサーバ)

ACMで証明書取得

ALB (httpsリスナー)

Route53でドメイン割り当て

1 で「リクエスト -> Route53」の流れを用意
2,3 で「ALB -> EC2」の流れを用意
4 で「Route53 -> ALB」の流れを用意

のようなイメージです。

Route53 ドメインの設定

AWSマネジメントコンソールでRoute53に進む

「ホストゾーンを作成」を押下

もう一度「ホストゾーンを作成」を押下

すると右側にホストゾーン設定の画面が出てくるので予め取得してあるドメインを「ドメイン名」の部分に入力し下の「作成」を押下

するとホストゾーンが作成されたので、以下のようにできているのかを確認。

次にドメインにネームサーバの設定をします

※今回は「freenom」を使っています

自分のドメインの一覧画面で各ドメインの右側にある「Manage Domain」を押下

するとこのような画面に入るので、

「Management Tools」の「Nameservers」を選択

「Use custom nameservers」にチェックを入れるとフォームが出てくるので
既に用意したRoute53 のホストゾーンの「タイプ:NS」の値4つをそれぞれ入れていきます

入力後「Change Nameservers」を押すと完了です

ACMでSSL証明書取得

AWSのCertificate Managerを選択し、「証明書のリクエスト」を押下する

右下の「証明書をリクエスト」を押す

そのまま右下の「確認」を押下

右下の「確認とリクエスト」を押下

ドメインの「▶」押すと出てくる、「Route53でのレコードの作成」の青いボタンを押し、

その後「続行」を押下

直後は画像のように検証保留中となっていますが、この部分が「発行済み」に変わると完了です

ALB設定 (httpsリスナー)

EC2のサイドバーから「ロードバランサー」を選択して「ロードバランサ―の作成」を押下

「Application Load Balancer」の「作成」を押下

プロトコルで「HTTPS」を選択

「アベイラビリティゾーン」はEC2インスタンスがあるところを含めて2つ選び、
右下の「次の手順：セキュリティ設定の構成」を押下

上で作った証明書を選択して、右下の「次の手順：セキュリティグループの設定」を押下

EC2インスタンスが入っているセキュリティグループをせんたくして
右下の「次の手順：ルーティングの設定」を押下

「新しいターゲットグループ」を選択し、任意の「名前」を付けた後
右下の「次の手順：ターゲットの登録」を選択

ここではターゲットグループに新しくEC2インスタンスを追加します。
下にはまだ未追加のインスタンスが一覧表示されているので、今回ALBで振り分ける先の
インスタンスを選択し、

「登録済みに追加」を押す。

すると、画面上部の登録済ターゲットの一覧に追加されるので、
そのことを確認後、画面右下の「次の手順：確認」を押下。

今までの設定を確認後、右下の「作成」を押下。

※「セキュリティグループ」のインバウンドのタイプで
httpsを追加していない場合はこのタイミングでしておきましょう

Route53でドメイン割り当て

「Route53」の設定画面に移動し、上記で作成した「ホストゾーン」を選択、「レコードセットの作成」--> 右の「エイリアス先」で作ったALBが一覧に表示されているのでそれを選択後「作成」を選択。

※サブドメインを指定したい場合は「名前」の欄にサブドメインを指定すれば可能です。

これで、今設定したドメインにhttpsアクセスできるようになりました。

参考記事

AWS：無料でSSL証明書を取得する方法

無料ドメイン(.tk)とRoute53を利用して0円でHTTPS環境を設定してみた

AWSのサービスでドメインを取得しALBでSSLで接続出来るようにする

ALBとバックエンドEC2間をHTTPS通信させてみた

AWSでWebサイトをHTTPS化その1：ELB(+ACM発行証明書)→EC2編

⇊僕は今回「freenom」使ったので参考にしました。

AWS SESで送信ドメイン認証を設定する

[ACM] SSL証明書発行時のドメイン認証メールをSESで受け取ってみた

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T12:53:03+09:00

CloudFormationでCloudWatchAlermを作成する

はじめに

ぐぐってもサンプルがでてこなくて、公式ページ見ながら作成したのでメモ。
いくつもLambda関数を作成しており、マネジメントコンソールで手動で作成するのが面倒なため、CloudFormationでコピペでできるように作成。

テンプレート(yaml)

Lambdaで実行時間が3秒を超えたときのアラーム。
1分の間に実行時間の最大値が3秒以上の回数が1回を超えたときにアラームをだす。
SNSにアラーム情報を送っている。
AWSTemplateFormatVersion: 2010-09-09
Resources:
  sample:
    Type: 'AWS::CloudWatch::Alarm'
    Properties:
      Namespace : AWS/Lambda
      AlarmName : lambda-duration-alarm-sample # アラーム名(自由に設定する)
      AlarmActions :
        - arn:aws:sns:ap-northeast-1:123456789012:sns-alerm # アラーム時に実行するSNSのarn(必須ではない)
      MetricName : Duration # 実行時間なのでDurationを指定
      ComparisonOperator : GreaterThanOrEqualToThreshold # 以上を表す
      EvaluationPeriods : 1 # 閾値を何回超えたときにアラーム状態にするか
      Period : 60 # 60秒
      Statistic : Maximum # 最大値
      Threshold : 3000 # 3秒(ミリ秒指定)
      Dimensions :
        - Name : FunctionName
          Value : sample-lambda
指定できる値

MetricName

メトリクス名を指定する。
AWSリソースにより指定する値が異なる。
メトリクスの作成画面のメトリクス名から指定できる値が見れる。

呼び出し回数でアラームを設定したい場合は、「Invocations」を指定する。

ComparisonOperator

指定する値意味

GreaterThanOrEqualToThreshold 以上

GreaterThanThreshold より大きい

LessThanOrEqualToThreshold 以下

LessThanThreshold より低い

Statistic

指定する値意味

Average 平均

Maximum 最大値

Minimum 最小値

SampleCount サンプル数

Sum 合計

Dimensions

公式ページ見ても指定の仕方がわかりませんでした。
マネジメントコンソールで作成画面を表示して設定しました。
サンプルの例だと下記の箇所を見ました。

複数設定する必要なときもある。

上記のようなときは、Dimensionsは下記のように複数設定する。
AWSTemplateFormatVersion: 2010-09-09
Resources:

・・・(省略)

      Dimensions :
        - Name : TableName
          Value : sampletable
        - Name : Operation
          Value : Query
最後に

CloudFormationをバリバリコーディングできる人がいるとしたらすごいなぁと思います。
1行定義するにも調べながら書いていて苦労しています。

指定する値	意味
GreaterThanOrEqualToThreshold	以上
GreaterThanThreshold	より大きい
LessThanOrEqualToThreshold	以下
LessThanThreshold	より低い

指定する値	意味
Average	平均
Maximum	最大値
Minimum	最小値
SampleCount	サンプル数
Sum	合計

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T12:01:02+09:00

AWSのrootアカウントでMFA設定時に「アクセス権限が必要です」と出た時の話

前提条件

認証アプリ：Google Authenticator (Google 認証アプリ)

結論

認証アプリへ登録したアカウントを、認証アプリ内から一回消して、QRコードをすぐ読み直しましょう。

当初

AWSのrootアカウントへ、MFA(Multi Factor Authentication)を有効化しようとしたんです。
しかし、アクセス権限が必要ですと出てきて進みませんでした。
説明文章にある認証コード１、認証コード２、連続の意味を思い出せず、ちょっと四苦八苦してた時に、
「ああ、順次表示されたコードを2回連続で入力するのね」
と理解したのですが、それでもダメでした。後にググって、同じ様に若干ハマってた人がいたので、手順はOKと判断しました。
しかし、何故かアクセス権限が必要ですがまだ出ます。
rootなんだから、アクセス権限が必要です≠IAMのアクセス権限が必要ですだよなぁ・・・と思いつつ、IAMユーザにアクセス権限を付加したりなんだりと無駄な事をやり・・・

解決

もう一度、rootアカウントのMFA有効化を試し、
「一回認証アプリへ登録したアカウントに異常があるかもしれない」
と判断し、認証アプリへ登録したアカウントを認証アプリから削除、登録し直しました。
→この行動を取った理由は、以前MFA有効化をした時用に別のモバイルデバイスがあって、
新旧の認証アプリで表示されていた認証コードが不一致だったので、
時間なのかsaltなのかは分からないけども、認証コードの仕組みで違いが出たのだろうなぁ・・・と想像したためです。

で、結論は先に書きましたが、MFA有効化は成功し、ログアウトしてサインイン、認証コードが通る事を確認出来ました。
認証コードをフワっとした理解のまま使っていたので、小一時間無駄にしてしまいました。
これを機会に、認証コードについての理解を少しだけでも仕入れてみました。

認証コードについてのザックリした理解

↓ググって掴みに良さそうな記事を見つけたのでリンク貼っておきます。
Google 認証システムの仕組み(sekika.github.io)

元仕様

RFCなんですねー、6238です。

仕組み

ほぼワンタイムパスワードを作って認証する仕組みです。
準備や手順は非常に単純で、

QRコードを読み込むと、サーバが生成した秘密鍵を受け取れる

なので、QRコードを読み込んだ時点でサーバとクライアントで秘密鍵を共有した状態になります。

30秒間だけ有効になるワンタイムパスワードを作っている

クライアント側では30秒ずつ別のパスワードが表示されるのは、これが理由

ザックリ図解
<<準備: 秘密鍵を盗まれたらOut>>
[      ケータイ電話   ]          [     サーバ     ]
秘密鍵 <- Google認証アプリ   <-   QRコード <- 秘密鍵

<<認証: 確認コードを盗まれたらOut(ただし約30秒間)>>
[      ケータイ電話   ]          [     サーバ     ]
           秘密鍵   ->           <- 秘密鍵
現在時刻 -> カウンタ -> 認証コード <- カウンタ <- 現在時刻
補足

QRコード以外にもBase32文字列でも認証アプリへ登録可能だそうです。

参考リンクにもある通り、中間者攻撃を防ぐ仕様は無いらしいので、 30秒間はずっと有効なパスワードという扱いなので、One-Period Passwordと呼んだ方が適切に思えます。 (サーバ側で、「一回認証OKになったら、次の認証コード発行までは同じ認証コードは無効化」としておけば、本当にワンタイムなパスワードになりますね)

結局、手順をどう誤ったのか

おそらくは以下の通りでしょう。

「MFAの有効化」で認証アプリへQRコードを読み込み → 秘密鍵を認証アプリへ保存した

「認証コード１」、「認証コード２」と「連続」の意味が分からず、MFA有効化に失敗したので一旦「キャンセル」した → おそらく、この時点でサーバ内の秘密鍵は無効化されたのでしょう

ヘルプを調べたりググったりして情報を得てから再度MFA有効化のためにQRコードを読み込み、しかしMFA有効化に失敗した →QRコードの再読み込みでは、認証アプリ内に既に作成した秘密鍵は上書きされなかった、しかもサーバ内には新しい秘密鍵が作成されたので、認証アプリとサーバとの間で秘密鍵の不一致が発生と推論します。(秘密鍵を照合したいですが、公開してもらえないでしょうから。。)

小一時間経過後、認証アプリ内のアカウントを削除し、QRコードを再読み込みする事で、MFA有効化に成功

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T11:46:06+09:00

AWSクラウドプラクティショナー受験記録

AWS クラウドプラクティショナーを受けたので勉強した内容と方法を残します

勉強期間2週間くらいでクラウドプラクティショナー受けました。
ご参考まで。

前提知識の有無

AWSは遊びでアカウント登録したくらい。
特に何も触ってません。
EC2、SQS、S3くらいは知ってたかな。

教材

参考書
とりあえず買ってみただけですが、結構まとまっていてよかったです。
読み物として１週、問題だけ解く形でもう１週。計5時間くらい。

ホワイトペーパー(アマゾンウェブサービスの概要)
とりあえずサービス名を覚えましょう。
上から下まで１回読んで、受験前にもう１回舐めれば大体OK。

ホワイトペーパー(AWS Well-Architected フレームワーク)
AWSの各サービスを組み合わせる際の考え方が書いてあります。
試験で問題読むときに前提とされている内容なので、理解はしましょう。
大した事ないです。冗長に組めよ。スケーラブルにするのよ。極力お安くね。って書いてあるだけ。

AWS Cloud Practitioner Essentials
AWSが提供してくれているお勉強動画。

やったこと

ホワイトペーパーをさらっと眺める。　
概要とアーキテクチャ。2～3時間もあれば読めます。
とりあえず名前と出来ることくらい憶えておきましょう。
試験では地味にサービス名を選ぶだけの問題も出ました。snowmobileとか。。。

白本を読む
大体4時間くらいで読めました。
ホワイトペーパーで出てきたサービス名をくっつけて雰囲気を掴む感じ。
白本読んでてよかったなー。と思ったのは請求回り。
技術屋さん的にはほぼ興味ないんだけれども、問題としては割と出るので注意。

お勉強動画見る。
全部で6時間以上あるので思った以上に苦痛。
でも、まぁ通過儀礼と思って観ましょう。
ここで、これ全然しらねーわ。とか思うところがあったら白本読むなりググるなりしましょう。

試験当日。
白本の章末問題だけをつらっと舐める。
ホワイトペーパーのサービス名を一通り見返す。
上記だけやって受験。

結果

平日は1日2時間。試験前日と当日午前で詰込みした結果、無事合格。
ちなみに合格時の点数は913/1000点。(合格ラインは700点)

感想

実は参考書が思ったより早く読み終わったので同じシリーズのアソシエイトも買ってみたりしました。
中身も一通り読んだのですが、クラウドプラクティショナーとアソシエイトでは視点が違う感じがしました。
クラウドプラクティショナーは本当にプリ向けというか、費用面やAWSのメリデメの話。アソシエイトはサービスの中の話というか。そんなイメージでした。
なので、いやーAWS触ったことないんだけどねー。みたいな人もプラクティショナーであれば気負わずに受けても大丈夫かと。

以上。

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T07:44:49+09:00

(初心者向け)S3とそのアクセス管理の方法まとめ

はじめに

AWSの基本サービスのS3ですが、アクセス管理がややこしいので整理するために書きました。ざっくりです。間違ってたら教えてください。

S3とは

Simple Storage Service
AWSのストレージサービス。容量無制限（従量課金）で安価、障害時の耐久性に優れている。データの保存・バックアップの用途のほか、静的ファイルをアップロードしてWebページとして公開することもできる。

用語

オブジェクト・・・S3に保存するファイル
バケット・・・オブジェクトの置き場所。フォルダみたいなもの。
キー・・・オブジェクトを指定するための一意の文字列。（オブジェクトの名前）

S3でのアクセス管理

デフォルトでは全てプライベート（バケット、オブジェクトを作成したAWSアカウントのみがアクセスできる）。
アクセスポリシーによって許可・拒否を定義する。

アクセス許可の流れ

S3はリクエストを受け取るとアクセス権があるかどうかのアクセスポリシーを確認し、許可するかを決める。

アクセスポリシーの種類は以下
・ユーザーポリシー
・バケットポリシー
・ACL
　・バケットACL
　・オブジェクトACL

ユーザーポリシー

=IAMでのアクセス管理
「このユーザーは何ができるか」を定義する。

バケットポリシー

「このバケットには誰がアクセスできるか」を定義する。
IPアドレスでの制限やMFA(多要素認証)制限、CloudFrontからのアクセスのみ許可する・・・など。

ACL

アクセスコントロールリスト
ユーザーポリシー、バケットポリシーより優先順位は低い。通常はユーザーポリシー、バケットポリシーで制御し、さらに細かい制御が必要な場合にACLを用いる。

バケットACL

バケットACLに関しては公式に以下の記述があります。

バケット ACL の使用が推奨される唯一のケースは、Amazon S3 のログ配信グループに、バケットへのアクセスログオブジェクトの書き込みアクセス許可を付与する場合です。

アクセスポリシーのオプションを使用するためのガイドラインより

オブジェクトACL

バケットポリシー、バケットACLがバケット単位であるのに対し、オブジェクトACLはオブジェクト単位でのアクセス管理。特定のオブジェクトに対しての制御が必要な場合に用いる。
バケット所有者が他のAWSアカウントにオブジェクトのアップロードを許可する場合は、オブジェクトACLでアクセス許可する必要がある。

その他

他に、ブロックパブリックアクセス設定というものもあり、リソースへのパブリックアクセス(公開)を制限できる。

参考

Amazon S3とは
 Amazon S3 リソースへのアクセス許可の管理の概要
 20190220 AWS Black Belt Online Seminar Amazon S3 / Glacier

さいごに

アクセス管理の細かい制御や関係については公式や他に良い記事がたくさんあるのでそちらを見ていただければと思います。
以上、どなたかのお役に立てば幸いです。

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T01:42:10+09:00

【AWS】複数のAWSアカウントを管理するためにStackSetを活用する #1/2【Multi Accounts】

はじめに

AWSを活用している企業のでは多くの場合、複数のAWSアカウントを取得・運用していると思います。数が増えれば増えるほど管理が煩雑になってくると思います。
管理の仕方は様々あると思いますが、本稿では最低限こうしておけば何とかなる、という観点でのベストプラクティスを紹介します。
なお本稿において、CloudFormationという名称をCFnと略すことがありますのでご留意ください。

TL;DR

全AWSアカウントでCloudFormation StackSetを使えるようにしておけばとりあえず何とかなる

AWS Organizationsには、実運用上必要な管理機能が少ない

AWS Control Towerは人類にはまだ早い気がする

基本的な考え方

AWSアカウントを管理する上で考えるべきことはたくさんあります。
CloudTrailsでAWS APIの実行ログを取得・安全な場所に保存する、least privilegeの原則に基づき必要なユーザに必要な権限を付与する、などなど。
挙げていったらキリがないのですが、管理対象AWSアカウントに任意のAWSリソースを確実に作る／設定する／削除する、という手段が無いことには始まりません。
本稿ではこれにフォーカスします。

マルチアカウントに関するベストプラクティスとしては下記の資料にまとまっていますので、敢えて同様の内容を記述することはしません。

AWS におけるマルチアカウント管理の手法とベストプラクティス
https://d0.awsstatic.com/events/jp/2017/summit/slide/D4T2-2.pdf

CloudFormationにはStackSetsという機能があり、これは複数のAWSアカウントに対して同一のStackを作成できる機能になります。
この機能を活用することで、保有しているAWSアカウントすべてに対し、必要なAWSリソースを作成／削除できます。
StackSetを作るためには、対象のAWSアカウントに必要なIAM Roleを作っておく必要がありますが、これさえ済ませておけば、あとはどうとでもなります。

AWS Control Towerというサービスがつい最近リリースされましたが、
AWS Organizationsに参加済みのAWSアカウントには適用できないことから、既存のAWSアカウントに適用するのはかなり難しいものとなります。
そのため、本稿ではAWS Control Towerについては概要を確認するにとどめます。

CloudFormation StackSets

概要は上述した通りで、複数のAWSアカウントに対し、同一のStackを作成することができます。

Working with AWS CloudFormation StackSets - AWS CloudFormation
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html

以下からその仕組みを説明します。

まず、重要な概念として以下のものがあります。

Administrator account

Stack setを作成するAWSアカウント

原則として、Stack setに関する作成／更新／削除作業は、このAWSアカウントのみが対象となる

StackSet用のIAM Role (AWSCloudFormationStackSetAdministrationRole) は事前に手動で作っておく必要がある

AWSCloudFormationStackSetExecutionRole のRole名は固定（他のRoleを指定して利用することはできない）

Target account

Stack setに基づき、実際のCFn Stack（Stack Instance）が作成されるAWSアカウント

StackSet用のIAM Role (AWSCloudFormationStackSetExecutionRole) は事前に手動で作っておく必要がある

AWSCloudFormationStackSetExecutionRole のRole名は固定（他のRoleを指定して利用することはできない）

Stack Set

Administrator accountに作成される、Stack setの設定

ただしAdministrator account自身には、指定しない限りは実際のCFn Stack及びAWSリソースは作らない（Administrator account自体をTarget accountとすることは出来、この場合はその限りではない）

利用するCFn templateは、通常のものと違いがない

CFn templateへのparameter設定も、通常のそれと違いがない

Stack Instance

Administrator accountで作成されたStack setをもとに、各Target account上で作成されるCFn Stack

Target accountにAWS Management Consoleでアクセスすると、CloudFormationのDashboardから参照できる

実体として、「StackSet-{{StackSet名}}-{{ランダム文字列}}」といった名称のCFn Stackとして生成されている

基本的な動作は以下のようになります。

全AWSアカウントに作成したいAWSリソースを定義したCFn templateを作成し、Administrator account上でStack setを作成する。併せて、Target account上にStack instanceを作成する。

Administrator accountのCloudFormationサービスは、 AWSCloudFormationStackSetAdministrationRole をAssumeRoleする。

AWSCloudFormationStackSetAdministrationRole をAssumeRoleしたのち、各Target accountの AWSCloudFormationStackSetExecutionRole をAssumeRoleする。

各Target accountの AWSCloudFormationStackSetExecutionRole の権限で、CFn Stackを作成する。

これを図示すると下記のようになります。

公式ドキュメントのチュートリアルを試すと、よく理解できるようになります。

Prerequisites: Granting Permissions for Stack Set Operations - AWS CloudFormation
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-prereqs.html

Getting Started with AWS CloudFormation StackSets - AWS CloudFormation
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-getting-started.html

その他関連するAWSサービス

AWS Organizations

複数のAWSアカウントを管理することができます。出来ることは概ね以下の3つです。

簡単に新たにAWSアカウントを作成することができ、また作成されるAWSアカウント上に管理用のIAM Role（※）を作成することができる

作成されたAWSアカウントの請求は、masterアカウントにConsolidated Billingされる

OCP(Organization Control Policy)/SCP(Service Control Policy)を定義することで、各AWSアカウントで実行できるAWS APIを制御することができる

実運用上、各組織において必要なIAM Roleは、開発者用や管理者用、Billing確認用など何パターンかあると思います。AWS Organizationsには残念ながら、全AWSアカウントに対して必要なIAM Roleを作成する、といった機能はありません。CloudFormation StackSetを使え、ということなのでしょう。

※管理用のIAM Roleは、任意の名前を指定することができますが、そのPolicyの内容を指定することは出来ません。Permissions、Trust Relationshipsは下記の内容が設定されます。
Permissionsは、「AdministratorAccess」という名称のInline policyとして付与されます。
Permissions
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}
Trust Relationshipsは、masterアカウントのIAM EntityであればAssumeRole出来る権限が付与されます。（下記例では、AWSアカウントIDが123456789012となっている個所に、実際のmasterアカウントのAWSアカウントIDが入ります。）
Trust&nbs;Relationships
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
公式ドキュメントは下記にあります。

What Is AWS Organizations? - AWS Organizations
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html

AWS Control Tower

つい最近、AWS Control Towerという機能がリリースされました。これも複数のAWSアカウント管理を支援するためのサービスです。後述する「AWS Landing Zones」を実装したサービスで、AWS Organizationsを超強力にしたものと思えば良いでしょう。
AWS Control Towerをきちんと使いこなすためには、AWS Landing Zonesの理解は必須です。

概ね以下のことが行われます。

運用上便利になること

Account Factoryと呼ばれる機能で、AWSアカウントを簡単に新規作成できるようになる

AWS SSOが自動的に設定され、全AWSアカウント用のManagement Console用のポータルが生成される

セットアップ時に行われること

ログ収集用のAWSアカウント(Log archiveアカウント)、セキュリティ用のAWSアカウント(Auditアカウント)が必ず新規に作成される

GuardDutyでの検知内容を通知するためのSNS Topicが、Auditアカウントに生成される

GuardRailと呼ばれるポリシーの集合体がデフォルトで定義され、全AWSアカウントに強制されるようになる。GuardRailの実態は、SCP／AWS Config Rulesの集合体。

AWSアカウントの新規作成時に行われること

全AWSアカウントでCloudTrailが有効にされ、ログはLog archiveアカウントに集約される

全AWSアカウントでAWS Configが有効にされ、ログはLog archiveアカウントに集約される

全AWSアカウントでAWS Config Rulesが有効にされ、違反の検知内容はAuditアカウントに集約される？（未確認）

全AWSアカウントにGuardDutyが設定され、検知内容はAuditアカウントに集約される

GuardRailsが強制的に適用される。

OUの概念

Root OU/Core OU/その他OUの3種類がある

masterアカウントはRoot OUに所属する

Log archiveアカウントとAuditアカウントはCore OUに所属する

その他のAWSアカウントは任意のOUに所属させることができる

ただし、既にAWS Organizationsに所属しているアカウントを参加させるのが難いこと（不可能ではないが、大変）、SCPを既に活用している場合は競合することなどから、適用が難しいケースがあると思います。

個人アカウントでいろいろ試していましたが、意外とAWS Configの費用が嵩むので削除してしまいました。お陰でいくつか詳細未確認な箇所があります、すみません。

公式ドキュメントは下記にあります。

What Is AWS Control Tower? - AWS Control Tower
https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html

AWS Landing Zones

AWS Control Towerのベースとなる概念です。
「Landing Zones」というAWSサービスそのものは存在しないようです。

Landing Zone | AWS Solutions
https://aws.amazon.com/jp/solutions/aws-landing-zone/

おわりに

ここまで、CloudFormation StackSet及び関連AWSサービスについて見てきました。
次稿では、StackSetを利用して実際に必要なIAM Roleを全AWSアカウントに作成する作業について記述していきます。

参考URL

AWS におけるマルチアカウント管理の手法とベストプラクティス
 15分で教えるAWSの複数アカウント管理 - Qiita

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T01:20:06+09:00

Hyperledger Fabric v1.4 のサンプルアプリケーションを AWS EC2 で動かしてみる

はじめに

HyperledgerFabricって公式サンプル以外に実装例が全然なくて（特に日本語だと…）、色々と調べるだけでどんどん時間が溶けていきます。特に安定版としてリリースされた v1.4 の実装例はほとんど見つかりません。エンタープライズユースが中心で、 Qiita や GitHub などではオープンにしづらいということなんでしょうかね。

さて、この記事では以下のリポジトリのサンプルを AWS EC2 で動かしてみたので、その手順を備忘録的にまとめています。

Build Blockchain Insurance Application

サンプルを動かすまでの流れ

AWS EC2 (Ubuntu-18.04)でインスタンス作成

EC2でインスタンスを作成。OS は Ubuntu-18.04 を選択しておきます。インスタンスタイプは適当に t2.xlarge とかでよいです。

セキュリティグループは、SSHとカスタムTCPルールを設定します。SSHはポート22を、カスタムTCPルールではポート3000を空けておきましょう。

インスタンスへSSH接続

作成したインスタンスへSSHで接続し、ターミナルで操作していきます。

SSHで接続する際のユーザー名はubuntuであることに注意。普段はよくec2-userで入ることが多いので、ここで少しハマりました。OSがAmazonLinuxのときはec2-user、Ubuntuのときはubuntuなので注意。

Build Blockchain Insurance Applicationリポジトリをクローンする前に必要な環境を整えます。

DockerとDockerComposeをインストール

aptパッケージを更新
$ sudo apt-get update
HTTPS経由でリポジトリを使用できるようにパッケージをインストール
$ sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common
Dockerの公式GPGキーを追加
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
stableリポジトリの設定
$ sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
もう一度aptパッケージを更新
$ sudo apt-get update
Dockerをインストール
$ sudo apt-get install docker-ce docker-ce-cli containerd.io
sudoがなくても一般ユーザーがDockerを実行できるように設定
// ユーザーの確認
$ whoami
ubuntu

// 初期設定では使えない
$ docker ps
Got permission denied while trying to connect to the Docker daemon socket at ~

// 権限の確認
$ cat /etc/group | grep docker
docker:x:999:

// 権限の追加
$ sudo gpasswd -a ubuntu docker

// 追加されたことを確認
$ cat /etc/group | grep docker
docker:x:999:ubuntu

// Dockerが使用するソケットを一般ユーザーが読み込めるように
$ sudo chmod 666 /var/run/docker.sock

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
DockerComposeをインストール
インストール前に/usr/local/bin/へ移動
$ sudo curl -L "https://github.com/docker/compose/releases/download/1.24.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
実行可能権限を適用
$ sudo chmod +x /usr/local/bin/docker-compose
インストールの確認
$ docker-compose --version
docker-compose version 1.24.1, build xxx~
Node.js、nvm、npmのインストール

nvm（ノードバージョンマネージャ）をインストール
$ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.32.0/install.sh | bash

$ . ~/.nvm/nvm.sh
nodejsとnpmのインストール
$ nvm install 8.9.4

$ node -v
v8.9.4

$ npm -v
5.6.0
pythonのインストール

Ubuntu-18.04にはデフォルトでpython3が入っているので、python2は別途インストールする必要がある。
$ sudo apt-get install python
Gitのインストール
$ sudo apt-get install git
アプリケーションを実行

リポジトリのクローンを作成
$ git clone https://github.com/IBM/build-blockchain-insurance-app
Dockerへログイン
$ docker login
Ubuntuで実行する際、configファイルを一部修正します。
// フォルダを移動
// /build-blockchain-insurance-app/web/www/blockchain/

// vimで修正
$ vi config.js
/build-blockchain-insurance-app/web/www/blockchain/config.jsの９ライン目のisUbuntu: falseをisUbuntu: trueへ書き換え。

シェルの実行
$ cd build-blockchain-insurance-app

$ ./build_ubuntu.sh
これでしばらくするとネットワークが作成されて、ブラウザからアプリケーションを触れるようになります。

URL : http://ec2-xx-xx-xx-xx.compute-x.amazonaws.com:3000/

EC2インスタンスのパブリックDNSに:3000/を付ければOKです。セキュリティグループの設定でポート:3000を開放しているので、ブラウザで以下のページが見れるようになっていれば成功です。

おわりに

Hyperledger Fabric v1.4 のサンプルアプリケーションを動かすところまでできました。

SDKを使ったアプリケーション側の実装がまだよく分からないので動かしながら、勉強していくしかないですね。

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-28T01:07:27+09:00

【Windowsユーザーでクラウド初心者向け】AWSのアカウントを作成してコンソールにサインインする

前提

Windowsユーザーでクラウドを使ったことがない人を対象に説明を進めていきます。

アカウントを作成する

Step1 : AWSのホームページを開く

AWSのホームページを開きます。
下記のリンクが壊れているときはググってください。

AWSホームページ

Step2 : アカウント開設の前に、アカウント作成の流れを読む

一番下まで画面をスクロールします。

《アカウント作成の流れはこちら》を右クリックして、『新しいタブで開く』を選択して別タブで開いてください。
（Ctrl＋クリックはなぜか効きません）

「アカウント作成の流れ」を一通り読む。

Step3 : アカウントを作成する

元のタブ（AWSのホームページ）に戻って、《今すぐ無料サインアップ》ボタンをクリックします。

「アカウント作成の流れ」を参考に必要情報を入力してアカウントを作成する。

注意点

以下の入力欄は全て半角アルファベットで入力してください。

AWS アカウント名

フルネーム

会社名

アドレス

市区町村

都道府県または地域

クレジットカード情報の登録が必要です。

無料枠のサービスは課金されませんが有料枠のサービスを使うと問答無用に課金されますので注意してください。

電話による認証が必要です。

Step 4 : コンソールにサインインする

AWSではメインメニューに当たる部分をコンソールと呼んでいます。

サインインする方法は2種類あります。

一つ目は、最初にアカウントを作成したEメールアドレスを使ってサインインする方法

このユーザーをルートユーザーと言います。

このユーザーを使ってサインインするのは最初のみでメインは二つ目の方法になる。

二つ目は、アカウント内で作成したユーザーを使ってサインインする方法

IAMというアカウント内にユーザーを作成するサービスがあるのでそこでユーザーを作成する。

理由については、AWS を安全に使うために（IAM のベストプラクティス）を見てください。

ルートユーザーを使用してコンソールにサインインする

《コンソールにサインイン》をクリックする。

アカウント作成時に登録したEメールアドレスを入力して《次へ》をクリックする。

パスワードを入力して《サインイン》をクリックする。

アカウント内（IAM）で作成したユーザーを使用してコンソールにサインインする

IAMのダッシュボードに表示されている、「IAMユーザーのサインインリンク」のアドレスのページを表示する。

「アカウント」、「ユーザー名」、「パスワード」を入力して《サインイン》をクリックする。
アカウントは、この画像では消えていますが通常はページを開いた時には入力されています。

注意

この画面を表示した後に、AWSのホームページの《コンソールにサインイン》をクリックしたらこのページが表示されます。

ルートユーザーでサインインした場合は、《ルートアカウント証明情報を使用してサインイン》をクリックしてください。

　 Tweet
Qiitaで続きを読む

20191028のAWSに関する記事は18件です。

AWS初心者が構築してみた①構成図作成

IAM...

AWSを勉強し始めた理由

Qiitaを書き始めた理由

目的

やること

前提条件

①構成を考える＆構成図作成

構成を考える

構成図作成

【CodeBuild】'NoneType' object has no attribute 'get'

エラーの内容

原因

S3に完全に同じファイルが上がってるか確認するロジックでちょっとハマったのでメモ。

S3のチェックサムを比較したい

おまけ Javaでのチェックサム確認方法

【SRE】SRE業務1ヶ月で考えたこと

SRE業務についたよ

システムを構築する上で常に意識すること

スケーラビリティ

冗長性

Read Replicaの数をどうするか

バックアップ

保存期間を何日に設定すべきか？(現状1日で設定)

運用性

コンテナ基盤構築

Kubernetes 参考記事

クラスタの構成

ゾーンクラスタ

ゾーンクラスタ

マルチゾーン クラスタ

リージョナル クラスタ

参考記事

Nodeをいくつに設定するべきか

なぜnodeが3個以上必要か

ReplicaSetの数をいくつにすべきか

CI/CDパイプライン構築

大事にすべき観点

Kubernetes デプロイ方法

Spinnaker

高度なデプロイに関する参考記事

Skaffold

参考記事

GitOps

何を用いるか

参考記事

Gitopsの例

デプロイに関して追加で考慮すべきこと

監視

監視で重要なこと

どこで何を監視するか

何を

どこで

データ収集

メトリクス

ログ

slack通知(アラート疲れさせないために)

ダウンタイム

監視ツール

Push型とPull型

Datadog

Prometheus

参考記事

可搬性の高いコンテナの設計

インフラのコード化

なぜIaCとCaCを区別したほうがよいか

なぜIaS(インフラのコード化)なのか

IaC(Infrastructure As Code)

主に使用されるツール

CaC(Configuration As Code)

権限設定

その他

クラウドのセキュリティの調査・検証

復旧手順の再現

インシデント発生時の対応のドキュメント化

カオスエンジニアリング

【SRE】SRE業務1ヶ月で考えたことをまとめてみた

SRE業務についたよ

システムを構築する上で常に意識すること

マルチゾーンクラスタ

リージョナルクラスタ

マルチゾーンクラスタ

リージョナルクラスタ

【AWS】ALB->ドメイン->SSL証明書メモ