How to test AWS resources locally with constraints

1/23/2020

I am having trouble testing my application locally, due to my machine having memory constraints.

My application utilizes about 10 different microservices where each service has shared/non-shared AWS resources. Up until now, I've been using localstack to deploy all required AWS mock services and docker to spin up the other dependent microservices. However, I think the overall system has gotten too large for my machine to handle. The only option I could think of is to leverage kubernetes then deploying everything to AWS for testing. I'm hesitant on doing so, as I don't want to spend money on a volunteer project.

Are there any other options to achieve this? Or should I just bite the bullet and pay on-demand? Thanks in advance.

-- Daniel Kim
amazon-web-services
docker
integration-testing
kubernetes
unit-testing

3 Answers

1/24/2020

Kubernetes on AWS? maybe too heavy for your request, but any way, recently EKS has reduced the price to 50%, if you think that's fine, go for it.

But I would recommnd to run with other tech, such as test kitchen with ec2 backend.

Using this driver (https://github.com/test-kitchen/kitchen-ec2) with test kitchen, you can run your test on a new-run ec2, after the test is done, the ec2 will be killed. Mostly, I will run spot instances only with the test kitchen, it will cost less

I have the experience with test kitchen, but there are also some other similar tools you can choice, just google them.

-- BMW
Source: StackOverflow

1/24/2020

First you should be setting resource requests and resource limits on your containers, this way you will have a control over the resources you assign/use. This is nicely explained on Managing Compute Resources for Containers.

Limits and requests for memory are measured in bytes. You can express memory as a plain integer or as a fixed-point integer using one of these suffixes: E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, Mi, Ki. For example, the following represent roughly the same value:

128974848, 129e6, 129M, 123Mi

Your Pod might look like this:

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

The following Pod has two Containers. Each Container has a request of 0.25 cpu and 64MiB (226 bytes) of memory. Each Container has a limit of 0.5 cpu and 128MiB of memory. You can say the Pod has a request of 0.5 cpu and 128 MiB of memory, and a limit of 1 cpu and 256MiB of memory.

Second, once you have your yaml deployments written down you can deploy them anywhere you want.

You can have a test run on GCP using their Free Tier which gives you $300 of credit for a year.

If you can set low requests you might be even be able to run it on your local machine using Minikube.

-- Crou
Source: StackOverflow

1/24/2020

I think the overall system has gotten too large for my machine to handle. The only option I could think of is to leverage kubernetes then deploying everything to AWS for testing

You have problems running 10 services locally, so you wanna add one more service to make it work? Math says it won't help :-)

How to test AWS resources locally with constraints

There is no need to run all services you have locally.
Each service should have a contract. Services collaborate assumes contracts of each other.
It's enough to run a service assuming contracts of other services without running them in fact.
If all services are mixed together without strong contracts, then there are much bigger problems and super powerful machine only hides them.

Or should I just bite the bullet and pay on-demand?

If you need to test all services together end to end, then it makes sense to test them on production like environment. If it's AWS, then use AWS. If it's on premise systems, then use the same.

And the last thing - let's separate concerns. Kubernetes (and Agile, Docker, DevOps and other buzzwords) doesn't relate here at all. At least assuming current state of the problem.

-- nickolay.laptev
Source: StackOverflow