続 カッコの付け方

AWSを始めとしたクラウドコンピューティング全般と、唯一神emacsにおける()の付け方についてだらだら書きます

localstack有料版をちゃんと使ってみる

localstack aws serverless

数ヶ月前にカッとなって課金だけしてたlocalstack Pro版を触ってみたのでその記録

f:id:iga-ninja:20201024010653p:plain

localstackのPro(有償)版とは？

localstackはaws-apiをローカル環境で再現するものです。それの有償版がPro。できること・できないことは
https://localstack.cloud/ を見てください。

だけど これだけ見てもよくわからんよね？ なので自腹を切って試してみた、というより面白そうだとおもったから、とりあえず課金した、英語を含めてもあんまり有償版のポストが見つからなかったため。

システム的な違い/機能Activateなどの話

Communitiy版をdocker-imageで無償で公開してるので、Pro版はどう違うんや？と思ってたけど、Pro版の場合は、API＿KEYを環境変数として仕込むことによって、認証サーバとおしゃべりして機能を有効・無効化しているはず。
なので本当に特定サイト以外インターネット全面禁止な社内とかからだと使えないかもしれない。14日のトライアルあるからそこで試してね。

あとは外部URL=dockerではないWebの画面が付きます。Community版でもあるらしいですが、いつまで続くかわからないらしい。便利かと言われると、ちょっと微妙、Readに特化しているので、AWSのManagedConsoleみたいにポチポチでリソース作ったりできない。あるだけマシかな程度です。

始めるぞ

とりあえず使ってみる。ネットにある古い情報を整理する意味でも書いているので、Communitiy版でも有用なこと書いてます。

APIキーを取得する

とりあえず課金する&サインインする。
次にAPIキーを取得する https://app.localstack.cloud/account/subscriptions から

localstackコマンドはいらない

https://app.localstack.cloud/docs#installation

にそって進めれば良いですが、いろいろ情報が古いんで補足しながら。 まず
pip install localstack と書いてありますが、無視します このコマンドなにができるかというと、docker-composeとかではなく dockerコマンドをラップしているコマンドなんですが、私の環境だと後述する ローカルDNSによる透過的なアクセス のために privileged で動かそうとするので、Linuxでuser-namespace使っているユーザー(開発者はほとんど使っている認識)と相性が悪い(というか動かない)です。「俺はLinuxなんて使う変態じゃないんや！」という人が大半だと思いますが、このローカルDNSによる透過的なアクセス、私の目から見て無理筋です。ほとんどの人がこの機能の恩恵を受けられない。詳しくは後述します。

docker-composeを書いて upする

localstackコマンドはほとんどの人にとって役に立たないと思うので、docker-compose書きます。Pro版との違いは 環境変数LOCALSTACK_API_KEYの有無と443のexposeです。ここで古い知識のUpdate、昔のlocalstackはサービスごとにListenポートを分離していましたが、最近それがなくなりました。4566で全サービス受けます。
https://app.localstack.cloud/docs#installation

の記載もUpdateされてないので、github上の最新をもとにこんな感じに

version: '2.1'

services:
  localstack:
    container_name: "${LOCALSTACK_DOCKER_NAME-localstack_main}"
    image: localstack/localstack
    network_mode: bridge
    ports:
      - "443:443"
      - "4566:4566"
      - "4571:4571"
      - "${PORT_WEB_UI-8080}:${PORT_WEB_UI-8080}"
    environment:
      - LOCALSTACK_API_KEY=[your-api-key]
      - SERVICES=serverless,cognito,rds,athena
      - DEBUG=${DEBUG- }
      - DATA_DIR=${DATA_DIR- }
      - PORT_WEB_UI=${PORT_WEB_UI- }
      - LAMBDA_EXECUTOR=${LAMBDA_EXECUTOR- }
      - KINESIS_ERROR_PROBABILITY=${KINESIS_ERROR_PROBABILITY- }
      - DOCKER_HOST=unix:///var/run/docker.sock
      - HOST_TMP_FOLDER=${TMPDIR}
    volumes:
      - "${TMPDIR:-/tmp/localstack}:/tmp/localstack"
      - "/var/run/docker.sock:/var/run/docker.sock"

あとは docker-compose up -d

awslocalコマンドいれる

awslocalコマンドは aws-cli で --endpoint=http://localhost:4566 とか打つのをかぶせたawscliです。
https://github.com/localstack/awscli-local

四の五の言わずにいれとけ、便利だから。補完が効かないので最初困りましたが、zshの人は

complete -C '/usr/local/bin/aws_completer' awslocal

確認してみる

ネットに転がってるやつで

awslocal s3 mb s3://test

この状態で https://app.localstack.cloud/resources/s3 みると

f:id:iga-ninja:20201024011650p:plain

機能拡張を見ていく

全部はみてません。この機能のテストをやりたいって考えている人は、そもそもAWS識者のはずなのでクドい説明は無しでいきます。

大前提、ポチポチではリソース作れない & リソースはすべてlocalマシン(Pro版でも)

最初に繰り返しですが、ポチポチ(＝Webブラウザ操作)でリソースは作れません。ので全部API操作です。terraformとかは頑張れば使えるかもしれないですがやってないです。
そういう目的で使うならば、CloudFormationは対応しているようです、がlocalstack用のテンプレートがそのまま本番で使えるかはもの次第でしょう。今思い出しましたがこれはserverless-frameworkのためですね。

さらに一応localstackという名前がついている通り、全てのリソースはlocalマシン上に格納されます。そのため本物のAWSのようなそこそこ巨大なりソースを複数個並べるとか無理です。なので、インフラのテストとして使うのはミニマムな構成を除いて今の所ちょっと守備範囲狭い。

RDS

どのように動くのか興味ありました

  • API部分は一応全部完備(ほとんどmockだけど)
  • DBエンジンとしては postgresがlocal-docker内で動く
  • RDS data APIが動く

のようです。

なんとMySQL非対応、そのうち対応するらしい。データストアとかを app.localstack.cloud 側で保存してくれるわけでもない。 メリットは RDS data APIが動くので、serverlessなLambdaから突くのにはいいかもしれない(よくできましたポイント)。

ElastiCache

  • API自体はRDSと同じ
  • Memcacheは非対応

普通に redisをdockerで上げればよくね？

ECS & ECR

ECR は ECS/EKS使うなら多分セットなので対応できているのよい、というかできてないと話にならない。
ECSも一応対応しているようですが、ドキュメントにもALBとかが絡む複雑な構成は無理って書いてある。
ServiceDiscoveryとかもまあ無理でしょ、対応できてもだいぶ未来になりそう。
現状だとあんまりテストにならないな、素直にAWS使ったほうが早いといった印象。

EKSはご想像どおりです。ECSよりもっと複雑なんでまともに使えるようになる未来はまだまだ先。

Athena

余力があったら実際に試すまでやってみようと思ってる、が正直微妙。Docから抜粋

Note: In order to use the Athena API, some additional dependencies have to be fetched from the network, including a Docker image of apprx. 1.2GB which includes Presto, Hive and other tools. These dependencies are automatically fetched when you start up the service, so please make sure you're on a decent internet connection when pulling the dependencies for the first time.

結局LocalでPresto回してるのと同じなんで、S3にクエリがかけられたとしてもGlueカタログとはまた違う代物なので、完全にAthenaとは同じにならない。
それとGlueクローラがないのでデータを用意してスキーマを更新してとかをSQLベースでやらなきゃならないので、そんな暇あるなら本物のAWSでやればええとなる。
まだ試してないのでわからないが、GlueカタログがないAthenaが動いてもほとんど意味ない感はする。EMRの、PrestoやるついでにReadyとしたんかな。

IAM Security Enforcement

良くできましたなポイントです。 2020/10/25時点では正直なところ微妙な機能。使えばすぐわかりますが、これを有効にするとDynamoDBが使えなくなる(Deniedとログに出る、つまり仕様)ので存在意義が見当たらない。

認証だけでなく・認可(Policy)が通ります。 サンプルとしては Credentialだけを発行して、 s3 mb 叩いてNG policyをちゃんとつけて mb成功させてます。リソース縛りとかに対応しているか、他のサービスもちゃんと動くのかは試してませんが、これがちゃんと実装できてれば素直にすごい。

ただ、経験上わかっていることとして、IAM policyはとてつもなく複雑なので、localstackで検証してOKなものがAWSでも同じように動くかは疑問です。完全実装はちょっと無理じゃないかな労力的に。EC2はないもののLambdaはRoleが必須なのでちょっと試してみる。

IAM policyどうやってるの？

ちょっと調べてみた。実装上はmotoから借りているものが多く、motoも一応認証・認可の挙動ができるらしい。
https://github.com/spulec/moto/blob/master/README.md#iam-like-access-control

どちらの実装も読んでみたけど、リソース縛りとか、S3以外のサービスでは動作しなさそう。ToDoにも書かれていたが、リソース絞りとか完璧にやろうとすると、作製済みリソースをどこかに保持しないといけないので、単なるmockの範疇を大きく超えることになる。localstackは単なるmockではないので拡張実装としてどこまでやれるかは見ものだが、これは大変な作業になりそう。

Configuring Local DNS Server

前半に書いた透過的なローカルDNSアクセスです。これは無理筋です。
どういうふうにやるかというと、経典みたいに本ブログに何度も出てきているMITM的なやり方です。 amazonaws.com の名前解決を横取りして、localstackに流すことによって --entrypoint=localhost...の指定を無しにする魂胆。DNSを捻じ曲げてhttps通信したら何が起こるか。「そうだね。証明書エラーだね。」

Note: When you configure transparent execution mode, you may still have to configure your application's AWS SDK to accept self-signed certificates. This is a technical limitation caused by the SSL certificate validation mechanism, due to the fact that we are repointing AWS domain names (e.g., *.amazonaws.com) to localhost. For example, the following command will fail with an SSL error:

これで transparent execution mode って言えるんかね？

CloudFormation Support & Serverless Integrationのextended

何がextendedなのかまだ調べられてない。今私は結構serverlessから離れてしまっているので、やってみます。serverless(sls) が CloudFormation必須なの忘れてた。

感想

  • serverless開発のローカル環境としては良さそうだが
    • Communitiy版と比較して明確なプラスは Cognito & API Gateway V2かな
  • インフラエンジニアがインフラのテスト(コード上)をやるための実験場としてはまだまだ無理
    • そんなやつおらへんと思うけど、terraform apply を localstack にぶち当てることができてもほとんど mockなので幸せにはならん
  • (ビック)データ系のサービスは対応とはあるものの、本物のAWSとの乖離が大きすぎて使い物にならない
    • 練習台・入門用としても逆に難しくてだめ

役に立つかは人それぞれ、14日のトライアルでちゃんと使って見極めてください。