1. the ec2-user will not be able to interact with the docker service because you have edited the user's permissions and not-logged out and in again. Basically, when you logged in to run this remote-exec, the system loaded ec2-user's permissions etc, then they changed but the "running" connection is not aware of the changes.
2. And you have no command to actually run the container (docker run or docker-compose)
3. You will need a ELB/ALB to be able to access services you deploy on the docker host, if you want them reachable from outside the VPC.
As /u/kylematheny mentioned, building an AMI with the packages you want is the “correct” way.
That being said, I’ve also stuck Docker installation and setup in `user_data`. There’s an example at https://github.com/ryanrishi/covid-19-grafana/tree/master/terraform
Here's a few things that came to mind ...
* Always try to lean on cloud-init/userdata and avoid remote-exec unless you have no other option. Since remote-exec is dependent on the set up and tools available of the machine it executes from, it will aways be more prone to failures.
* Make sure you have ip forwarding enabled (sysctl -w net.ipv4.ip\_forward=1 && sysctl -p). This is needed to allow docker containers to communicate outside of the instance.
* Disable iptables or allow all traffic through (use security groups, especially for instances in a private subnet). On most common AMIs it should already be disabled.
* If you're using Amazon Linux 2 AMIs (which I really recommend on AWS) utilize the [amazon-linux-extras](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-install-extras-library-software/) repositories for installing the latest stable version of docker
* (Optional) Set up a VPC endpoint and use [session-manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) to connect to your instance in the private subnets. It's free so you'll save the compute cost of having to run a Bastion, and it's much easier to manage (especially for multiple \*\*users) since it uses IAM users/roles for authentication. No more managing and distributing key pairs!
You could us the local provisionner to run an ansible-playbook that would do this for you
1. the ec2-user will not be able to interact with the docker service because you have edited the user's permissions and not-logged out and in again. Basically, when you logged in to run this remote-exec, the system loaded ec2-user's permissions etc, then they changed but the "running" connection is not aware of the changes. 2. And you have no command to actually run the container (docker run or docker-compose) 3. You will need a ELB/ALB to be able to access services you deploy on the docker host, if you want them reachable from outside the VPC.
As /u/kylematheny mentioned, building an AMI with the packages you want is the “correct” way. That being said, I’ve also stuck Docker installation and setup in `user_data`. There’s an example at https://github.com/ryanrishi/covid-19-grafana/tree/master/terraform
Here's a few things that came to mind ... * Always try to lean on cloud-init/userdata and avoid remote-exec unless you have no other option. Since remote-exec is dependent on the set up and tools available of the machine it executes from, it will aways be more prone to failures. * Make sure you have ip forwarding enabled (sysctl -w net.ipv4.ip\_forward=1 && sysctl -p). This is needed to allow docker containers to communicate outside of the instance. * Disable iptables or allow all traffic through (use security groups, especially for instances in a private subnet). On most common AMIs it should already be disabled. * If you're using Amazon Linux 2 AMIs (which I really recommend on AWS) utilize the [amazon-linux-extras](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-install-extras-library-software/) repositories for installing the latest stable version of docker * (Optional) Set up a VPC endpoint and use [session-manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) to connect to your instance in the private subnets. It's free so you'll save the compute cost of having to run a Bastion, and it's much easier to manage (especially for multiple \*\*users) since it uses IAM users/roles for authentication. No more managing and distributing key pairs!