Ready-to-run packaged version (docker or Lambda SAR?)

[jantman]

It would probably be helpful for people who don't have much Python experience/tooling to distribute awslimitchecker as a Docker container. I think we could just have the Docker Hub run automated builds for this, probably when we cut a new release tag. Alternatively, it might be better to have TravisCI do the build, so it could also run some smoke/acceptance tests against the container before deploying it.

[bflad]

For what its worth, here's a working Dockerized setup in our organization.

Dockerfile:

FROM python:3.5-alpine
ARG VERSION=0.11.0

RUN \
  pip install --upgrade --no-cache-dir pip setuptools virtualenv && \
  virtualenv awslimitchecker && \
  source awslimitchecker/bin/activate && \
  pip install --no-cache-dir awslimitchecker==${VERSION}

ENV AWS_DEFAULT_REGION='us-east-1'
COPY entrypoint.sh /usr/local/bin/
ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]

entrypoint.sh:

#!/bin/sh

source awslimitchecker/bin/activate
exec awslimitchecker "$@"

Build invocation:

docker build --build-arg VERSION=${VERSION} -t awslimitchecker:${VERSION} .

Invocation:

docker run --rm awslimitchecker:0.11.0 [AWSLIMITCHECKER_FLAGS]

[jantman]

Thanks so much, @bflad ! I'll need to see how the Docker Hub automated builds work (since I've only done manual builds and pushed them up), but that is very helpful!

[jantman]

Looks like there's a few out there: https://github.com/fordodone/docker_awslimitchecker , https://github.com/TradeCast/awslimitchecker-docker , https://github.com/krutisfood/docker_awslimitchecker

At some point I'd like to get an official container out. The Dockerfile above looks like what I'd use. I've just been too busy lately to get around to this...

[jantman]

So I'm thinking that what I'd really like is a Docker image that also has everything needed to run awslimitchecker standalone in ECS Fargate. So that would include the current awslimitchecker proper, plus a new command line entrypoint that:

• Can optionally read limit and threshold override configuration from a JSON file in S3
• Sets logging level based on an environment variable
• Can send notifications of problems via the following methods, controlled by environment variables:
  • SES formatted email, one per issue/limit, separate env vars for warning/critical destination
  • SES formatted email, one email for everything (all services/limits, warning/critical combined)
  • SNS message, one per issue/limit, separate env vars for warning/critical destination
  • SNS message, one message for everything (all services/limits, warning/critical combined)
  • PagerDuty Events, separate services for warning/critical, sent via events API with a reasonable key (account, region, service, limit) for de-duplication. Also send "resolve" POSTs for all OK limits.

I'm certainly open to feedback and will be open to PRs for other notification methods, but I think the above should give most people enough for a minimally-working awslimitchecker installation using only ECS Fargate and native AWS services.

[jantman]

I'm interested in feedback from @bflad and others on this... I've been thinking about it more, and I'm wondering if maybe the right way is to add Lambda support instead of Docker.

awslimitchecker is relatively lightweight; the largest region of the largest account that I have is pretty giant (1,700 EC2 instances, 2,500 volumes, 1,000 LBs, 600 RDS instances, ~400 ECS clusters, etc.) and a full awslimitchecker run for that region takes ~270 seconds. Now that Lambda's timeout is 15 minutes (900 seconds), I think most users should be able to complete a single-region run within that timeframe.

How would people feel about a Lambda deployment option?

Specifically, I'm thinking of:

• Produce a release artifact on GitHub that's suitable for direct upload to Lambda - i.e. release a ready-to-run Lambda source archive
• All configuration will be via environment variables
• Optional loading of limit and threshold overrides from JSON files in S3
• Logging level via environment variable
• Sending notifications via the options described in the previous comment - initially SES, SNS and PagerDuty - configured by environment variables
• Built-in support for tracing with X-Ray
• Example configurations for this in Terraform and CloudFormation
• Publish to the AWS Serverless Application Repository

[albuch]

@jantman Your propsal is basically the same architecture that AWS Limit Monitor is offering but with the benefit of additional limit checks that are not supported by TrustAdvisor.
I would opt for the lambda version instead of Docker if I had a joice.

[talbright]

One simple first step, is to add a lambda handler that converts the json input suitable for argv and invoke main. Redirect stderr/stdout to an SNS topic.

With that small amount of work users will have a workable lambda that can be invoked via a CloudWatch scheduled event.

Buildout with more advanced features as you suggested from there.

[bergkampsliew]

With regard to Lambda, maybe can consider to package and publish it through Serverless Application Repostiory https://aws.amazon.com/serverless/serverlessrepo/
It also makes deployment easier and getting started.

[jantman]

Yeah, that's definitely a good idea re: SAR, @bergkampsliew.

@talbright in terms of getting something simple runnable, I hadn't thought of just passing in an argv-like JSON. That's a pretty good idea. Thanks!

[jantman]

I'm now building an official Docker image of awslimitchecker, merged in #301. The image is now live on docker hub and relevant docs are live on ReadTheDocs.

I'll be doing some work over the next few days to add a few features that my employer needs, and then will also publish an example of running awslimitchecker as a scheduled task on Fargate.

I'm going to close this issue for now, since I feel that Docker should work for most people and is more flexible... and easier for me to maintain and test than Lambda / SAR.