数ヶ月前にカッとなって課金だけしてたlocalstack Pro版を触ってみたのでその記録
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 みると
機能拡張を見ていく
全部はみてません。この機能のテストをやりたいって考えている人は、そもそもAWS識者のはずなのでクドい説明は無しでいきます。
大前提、ポチポチではリソース作れない & リソースはすべてlocalマシン(Pro版でも)
最初に繰り返しですが、ポチポチ(＝Webブラウザ操作)でリソースは作れません。ので全部API操作です。terraformとかは頑張れば使えるかもしれないですがやってないです。
そういう目的で使うならば、CloudFormationは対応しているようです、がlocalstack用のテンプレートがそのまま本番で使えるかはもの次第でしょう。今思い出しましたがこれはserverless-frameworkのためですね。
さらに一応localstackという名前がついている通り、全てのリソースはlocalマシン上に格納されます。そのため本物のAWSのようなそこそこ巨大なりソースを複数個並べるとか無理です。なので、インフラのテストとして使うのはミニマムな構成を除いて今の所ちょっと守備範囲狭い。
RDS
どのように動くのか興味ありました
のようです。
なんと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開発のローカル環境としては良さそうだが
- インフラエンジニアがインフラのテスト(コード上)をやるための実験場としてはまだまだ無理
- そんなやつおらへんと思うけど、terraform apply を localstack にぶち当てることができてもほとんど mockなので幸せにはならん
- (ビック)データ系のサービスは対応とはあるものの、本物のAWSとの乖離が大きすぎて使い物にならない
- 練習台・入門用としても逆に難しくてだめ
役に立つかは人それぞれ、14日のトライアルでちゃんと使って見極めてください。
