Deploy to elasticbeanstalk via CLI deploy command

Question

I am running an elasticbeanstalk application, with multiple environments. This particular application is hosting docker containers which host a webservice.

To upload and deploy a new version of the application to one of the environments, I can go through the web client and click on "Upload and Deploy" and from the file option I select my latest Dockerrun.aws.json file, which references the latest version of the container that is privately hosted. The upload and deploy works fine and without issue.

To make it simpler for myself and others to deploy I'd like to be able to use the CLI to upload and deploy the Dockerrun.aws.json file. If I use the cli eb deploy command without any special configuration the normal process of zipping up the whole application and sending it to the host occurs and fails (it cannot reason out that it only needs to read the Dockerrun.aws.json file).

I found a documentation tidbit about controlling what is uploaded using the .elasticbeanstalk/config.yml file.

Using this syntax:

deploy: artifact: Dockerrun.aws.json

The file is uploaded and actually deploys successfully to the first batch of instances, and then always fails to deploy to the second set of instances.

The failure error is of the flavor: 'container exited unexpectedly...'

Can anyone explain, or provide link to the canonical approach for using the CLI to deploy single docker container applications?

Answer 1

Since you have asked for a link, I am providing a link which I initially used to successfully test and deploy docker using elasticbeanstalk cli.

Kindly see if this helps you as well: https://fangpenlin.com/posts/2014/11/25/running-docker-with-aws-elastic-beanstalk/

Answer 2

So it turns out that the method I listed about with the config.yml was correct. The reason I was seeing a partially successful deployment was because the previously running docker container on the hosts was not being stopped by EB.

I think that what was happening was that EB is sending something like

sudo docker kill --signal=SIGTERM $CONTAINER_ID instead of the more common sudo docker stop $CONTAINER_ID

The specific container I was running didn't respond to SIGTERM and so it would just sit there. When I tested it locally with SIGKILL it would (obviously) stop properly, but SIGTERM alone wouldn't stop it.

The issue wasn't the deployment methodology but rather confusion in the output that EB generated and my misinterpretation.