CircleCIでsls deployしようとしたらこんなかんじのエラーがでた。
Error: Cannot find module '/home/circleci/repo/node_modules/fs-extra/lib/index.js'. Please verify that the package.json has a valid "main" entry
こんなものはないっていわれている
/home/circleci/repo/node_modules/fs-extra/lib/index.js
git add -Aしてnode_modules/配下が全部GitHub上にPushされていて、CircleCIでnpm installしたときにそんなものはないと言われていた。
.gitignoreできちんとそこらへんを対象外にしてあげる
アサヒ飲料 モンスター パイプラインパンチ 355ml ×24本
CircleCIでLambda(Python)をServerless Frameworkをつかってデプロイしてみます。
GitHubにCommitされるとCircleCIでsls deployしてAWSにデプロイするようなイメージ。
手順です。
以下に役に立つページがあります。
手順5まですすめます。
CircleCIの設定ファイルであるconfig.ymlを作成します。
mkdir .circleci
touch .circleci/config.yml
config.ymlの中身はこんなかんじ。
Serverless Frameworkをインストールして、serverless-python-requirementsをインストールして、sls deployするだけです。
version: 2 jobs: build: docker: - image: circleci/python:3.7.6-stretch-node-browsers working_directory: ~/repo steps: - checkout - run: name: Install Serverless CLI and dependencies command: | sudo npm install -g serverless npm install - deploy: name: Deploy command: | npm install --save serverless-python-requirements sls deploy
CircleCIからSetup Projectして、Commit契機でうごくようにしておきます。
addしてcommitしてPushしてCircleCIをうごかします。
デプロイできました。
べんりですね
継続的デリバリー 信頼できるソフトウエアリリースのためのビルド・テスト・デプロイメントの自動化 (アスキードワンゴ)
Serverless FrameworkをつかってLambda(Python)をAWS環境にデプロイしてみます。
手順です。
今回デプロイするAWS Lambda用のServerless Frameworkのテンプレートを作成します。
serverless create --template aws-python3 --name requests-test --path ./requests-test
できました。
ls -l ./requests-test total 8 -rw-r--r--. 1 vagrant vagrant 497 Feb 2 07:16 handler.py -rw-r--r--. 1 vagrant vagrant 3201 Feb 2 07:16 serverless.yml
デプロイしたいLambdaのコードをかきます。
今回はhandler.pyを以下のように上書きしてしまいます。
requestsをつかってcurlするだけのPythonです。
import requests def main(event, context): response = requests.get('https://www.kabegiwablog.com/') print(response) if __name__ == '__main__': main('', '')
ローカルでちゃんと動作することがわかります。
python3 ./handler.py <Response [200]>
このhandler.pyの実行に必要なパッケージをrequirements.txtに記載してあげます。
pip3 freeze | grep requests > ./requirements.txt
こんなかんじ。
$ cat requirements.txt requests==2.22.0
serverless.ymlを以下のように編集してあげます。
service: requests-test provider: name: aws runtime: python3.7 region: ap-northeast-1 functions: requests-test-lambda: handler: handler.main plugins: - serverless-python-requirements custom: pythonRequirements: dockerizePip: true
serverless-python-requirementsをインストールしてあげます。
これにより、requirements.txtで依存関係を自動的にバンドルしてくれます。
npm install --save serverless-python-requirements
いよいよデプロイです。
以下コマンドを実行してあげると、AWS環境にLambda関数がデプロイされます。
裏でCloudFormationがうごいています。
$ sls deploy Serverless: Generated requirements from /home/vagrant/requests_test/requirements.txt in /home/vagrant/requests_test/.serverless/requirements.txt... Serverless: Installing requirements from /home/vagrant/.cache/serverless-python-requirements/f866cf90d6349902a899d904a8c7724b092b63ed16fa2530c859ec177d70c68e_slspyc/requirements.txt ... Serverless: Using download cache directory /home/vagrant/.cache/serverless-python-requirements/downloadCacheslspyc Serverless: Running ... Serverless: Packaging service... Serverless: Excluding development dependencies... Serverless: Injecting required Python packages to package... Serverless: Uploading CloudFormation file to S3... Serverless: Uploading artifacts... Serverless: Uploading service requests-test.zip file to S3 (1.92 MB)... Serverless: Validating template... Serverless: Updating Stack... Serverless: Checking Stack update progress... ......... Serverless: Stack update finished... Service Information service: requests-test stage: dev region: ap-northeast-1 stack: requests-test-dev resources: 6 api keys: None endpoints: None functions: requests-test-lambda: requests-test-dev-requests-test-lambda layers: None Serverless: Run the "serverless" command to setup monitoring, troubleshooting and testing.
できました。
removeで全削除できます。
sls remove
べんりな世の中になりましたね。
curlコマンドをPythonコードに変換します。
以下のサイトをつかうだけ。
これが
curl -k https://www.kabegiwablog.com
こうなる
import requests response = requests.get('https://www.kabegiwablog.com/', verify=False)
べんりですね
CentOS7にServerless Frameworkをインストールしてみます。
Node.jsが必要です。
以下の手順を参考にインストールしましょう。
これだけ
sudo npm install -g serverless
sls --version Framework Core: 1.62.0 Plugin: 3.3.0 SDK: 2.3.0 Components Core: 1.1.2 Components CLI: 1.4.0
できましたね
CentOS7にNode.js13.xをインストールしてみます。
curl -sL https://rpm.nodesource.com/setup_13.x | sudo bash -
これでyum install してあげればOKです。
Node.jsとnpmがインストールされます。
sudo yum install nodejs
確認してみます。
node --version v13.7.0
npm --version 6.13.6
できましたね
![Node.js超入門[第2版]](https://images-fe.ssl-images-amazon.com/images/I/513Ruzs3LjL._SL160_.jpg "Node.js超入門[第2版]")
CloudFrontでオリジンをS3にしているときに、設定は間違っていないのにCloudFrontのURLからS3のURLにリダイレクトされてしまって、Access Deiniedってなってんーーーーーーーーーー？？？？？？ってなるときの原因と対処法です。
基本的に全部以下に書いてある。
Amazon S3 での HTTP 307 エラーをトラブルシューティングする
Amazon S3 バケットを作成後、そのバケット名がすべての AWS リージョンに伝達されるまで、最大で 24 時間ほどかかる場合があります。その間に、S3 バケットと同じリージョンにないリージョンのエンドポイントにリクエストすると、「307 Temporary Redirect」レスポンスが返る場合があります。
これも書いてある。
Amazon S3 での HTTP 307 エラーをトラブルシューティングする
Amazon S3 オリジンで Amazon CloudFront ディストリビューションを使用する場合、CloudFront はリクエストをデフォルトの S3 エンドポイント (s3.amazonaws.com) に転送します。このエンドポイントは、us-east-1 リージョンにあります。バケットを作成後 24 時間以内に Amazon S3 にアクセスする必要がある場合は、バケットのリージョンのエンドポイントが含まれるように、このディストリビューションのオリジンドメイン名を変更します。たとえば、バケットが us-west-2 にある場合は、オリジンドメイン名を bucketname.s3.amazonaws.com から bucketname.s3-us-west-2.amazonaws.com に変更することができます。
実際にOrigin Domain Nameをkabegiwa-test-bucket.s3-ap-northeast-1.amazonaws.comといった形にして5分くらいでちゃんとCloudFront経由でやりたいことが実現できた。
意外とハマった。
CloudFrontのオリジンアクセスアイデンティティを使用して、CloudFront経由でのみS3バケット内のコンテンツにアクセスさせてみます。
CloudFrontのオリジンの設定で以下のように設定します。
RestrictBucketAccessをYesに、
Origin Access IdentityをCreate a New Identityに、
Grant Read Permissions on BucketをYes, Update Bucket Policyにします。
すると以下のようにオリジンに設定したバケットのバケットポリシーが自動で設定されます。
S3バケットに直接アクセスすると以下のようにAccess Deiniedになります。
しかし、CloudFrontのDNS名経由ではアクセスすることができます。
セキュアですね。
AWSCLIを利用してAWSアカウントをコマンド一撃で作成してみます。
これでいけます。
アカウント名とルートアカウントのメールアドレスを指定してあげるだけです。
aws organizations create-account --email myemail@example.com --account-name kabegiwablog
べんりですね
Amazon Web Services パターン別構築・運用ガイド 改訂第2版 (Informatics&IDEA)
ECS上でApacheを動かしてアクセスするだけのおはなしです。
具体的には以下のような構成です。
ECSに接続するLBを事前に作成しておきます。
リスナーをHTTPSで
ターゲットグループはポートを8080にします。ヘルスチェックは/healthで作成します。
ふつうにつくればもんだいないです。
ネットワークモードをbridgeにし、コンテナをhttpdで作成します。
また、ポートマッピングでホストポート8080をコンテナポート80にマッピングしておきます。
サービスの設定で、さきほど作成したタスク定義を起動するように設定する。
https://ALBのドメイン名でアクセスする。
It works!!!
ワインをのみながらかいている。
sudoでリダイレクトがしたくなった。
たとえば以下のようにやるとPermission Deniedってなってしまう。
sudo echo 'wawawa' > /etc/wawawa.txt bash: permission denied: /etc/wawawa.txt
bash -cをつかってあげる。
以下のようなかんじ。
sudo bash -c "echo 'wawawa' > /etc/wawawa.txt"
おぼえておく。
ALBにACM/SSL証明書を関連付けてみます。
画像のような感じです。
基本的なかたちですね。
ユーザからALBまではHTTPSで、ALBからEC2までの内部通信はHTTPです。
以下ですこしやりました。
ALBからのアクセスを受けるEC2インスタンスを設定してあげます。
セキュリティグループはALBからの通信を受けられるような設定のものをアタッチしてあげます。
以下のようなかんじの設定でALBを作成してあげます。
名前: すきななまえ
スキーマ: インターネット向け
IPアドレスタイプ: ipv4
リスナー: HTTPS
VPC: すきなVPC
アベイラビリティゾーン: すきなAZ
証明書タイプ: ACM から証明書を選択する
証明書の名前: 手順1 で取得した証明書の名前
セキュリティグループ: インバウンドに任意の場所からHTTPSが許可されたものを選択
ターゲットグループ: 新しいターゲットグループ
名前: すきななまえ
ターゲットの種類: インスタンス
プロトコル: HTTP
ポート: 80
ヘルスチェックのプロトコル: HTTP
ヘルスチェックのパス: /
手順2で作成したインスタンスを登録済みに追加する。
インスタンスにssh接続し、以下を実行してApacheの設定をしてあげます。
sudo yum install -y httpd
sudo mkdir -p /var/www/html
sudo bash -c "echo 'wawawa' > /var/www/html/index.html"
sudo systemctl start httpd
この時点でALBからインスタンスにアクセスできるかどうかを確認してみます。
ターゲットグループのステータスがhealthyかどうかを確認します。
ALBのDNS名からブラウザでアクセスして確認してみます。
https://ALBのドメイン名です。
証明書のドメインとALBのドメインが違うため、警告がでますが、無視してさきにすすみます。
wawawaと表示されればOKです。
ALBのDNS名をコピーし、Route53にCNAMEとして追加してあげます。
ホストゾーン: ACM取得したドメイン
タイプ: Aレコード
エイリアス先: 作成したALB
ブラウザからドメイン名でアクセスします。
HTTPSで通信ができているはずです！！！
べんりですね
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
お名前.comで取得したドメインの証明書をACMで取得してみます。
こんなかんじの手順です。
Route53でACMを取得するドメイン名でHosted Zoneを作成します。
作成されたときにできるNSレコードを控えておきます。
次の手順で使います。
続いて、お名前.comの[ドメイン設定]-[ネームサーバーの変更]へ遷移し、ACMを取得するドメインを選択、先の手順で控えたNSレコードを入力します。
インターネットの環境により、反映完了まで24時間から72時間程度かかる場合があるらしい。
マネジメントコンソールから[証明書のリクエスト]であとは画面にそってしすすみます。
検証方法はDNSによる検証で良いと思います。
画面にそってすすんでステップ5で[Route53でのレコードの作成]を選択してRoute53にCNAMEレコードを追加してあげます。
できました。
かんたんですね。
図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書
Kubernetes クラスタを切り替えます。
手順です。
$ kubectl config get-clusters NAME test.ap-northeast-1.eksctl.io wawawa.ap-northeast-1.eksctl.io
$ kubectl config current-context kabegiwa@wawawa.ap-northeast-1.eksctl.io
$ kubectl config use-context kabegiwa@test.ap-northeast-1.eksctl.io Switched to context "kabegiwa@test.ap-northeast-1.eksctl.io".
べんりですね
EKSクラスタを作成してpodをつくるまでのメモです。
手順です。
こんなかんじ
podはひとつだけ
作成に10分くらいかかる
$ eksctl create cluster --name test --nodes 1
kubectlで使えるようにconfigに追記させる。
$ eksctl utils write-kubeconfig --name test --kubeconfig ~/.kubeconfig
クラスタができている。
$ eksctl get cluster NAME REGION test ap-northeast-1
fargateではないのでnodegroupがインスタンスで動作している。
$ eksctl get nodegroup --cluster test CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID test ng-67463005 2020-01-02T04:08:54Z 1 1 1 m5.large ami-02e124a380df41614
podをつくります。
$ kubectl create -f sample-pod.yaml
apiVersion: v1 kind: Pod metadata: name: sample-pod spec: containers: - name: linux image: centos
podができている。
$ kubectl get pods NAME READY STATUS RESTARTS AGE sample-pod 0/1 CrashLoopBackOff 8 10m
むずかしいですね
Kubernetes完全ガイド (impress top gear)
