#terraform-aws-modules (2023-12)

@Josh B. thanks, please see a few comments

@Josh B. more comments

what happens after you see that “Mounting additional volume…” message?

Does Terraform fail or timeout with another message? Or does Terraform successfully apply the component and the instance itself fails to complete?

for reference, that message comes from this step of user-data https://github.com/cloudposse/terraform-aws-components/blob/main/modules/bastion/templates/user-data.sh#L3-L9

Yes, that’s correct. The message is coming from user-data. Terraform completes successfully but I am not able to access the instance as it is not completely setup yet.

I was able to reproduce this. checking for a quick fix

https://github.com/cloudposse/terraform-aws-components/pull/917

We’ve merged this PR now. You should be able to remove that userdata step and retry

Awesome! Thanks @Dan Miller (Cloud Posse) Will try it again tonight.

@Dan Miller (Cloud Posse) The instance seems to be now stuck on the docker installation step. I am including a portion of the system log:

[   96.330320] cloud-init[2216]: yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
[   96.331804] cloud-init[2216]: Cannot find a valid baseurl for repo: amzn2-core/2/x86_64
[   96.333142] cloud-init[2216]: Could not retrieve mirrorlist <https://amazonlinux-2-repos-us-east-1.s3.dualstack.us-east-1.amazonaws.com/2/core/latest/x86_64/mirror.list> error was
[   96.335805] cloud-init[2216]: 12: Timeout on <https://amazonlinux-2-repos-us-east-1.s3.dualstack.us-east-1.amazonaws.com/2/core/latest/x86_64/mirror.list>: (28, 'Connection timeout after 5000 ms')
[   96.338840] cloud-init[2216]: Dec 06 00:09:54 cloud-init[2216]: util.py[WARNING]: Package upgrade failed
[   96.437710] cloud-init[2216]: Dec 06 00:09:54 cloud-init[2216]: cc_package_update_upgrade_install.py[WARNING]: 1 failed with exceptions, re-raising the last one
[   96.440334] cloud-init[2216]: Dec 06 00:09:54 cloud-init[2216]: util.py[WARNING]: Running module package-update-upgrade-install (<module 'cloudinit.config.cc_package_update_upgrade_install' from '/usr/lib/python2.7/site-packages/cloudinit/config/cc_package_update_upgrade_install.pyc'>) failed
[   96.930433] cloud-init[2323]: Cloud-init v. 19.3-46.amzn2.0.1 running 'modules:final' at Wed, 06 Dec 2023 00:09:55 +0000. Up 96.86 seconds.
[   97.016364] cloud-init[2323]: Installing docker...

Are these two parameters required for the instance to start properly?

image_container: infrastructure:latest
image_repository: "111111111111.dkr.ecr.us-east1.amazonaws.com/example/infrastructure"

no those are not required. when we run this internally, we only pass these options:

components:
  terraform:
    bastion:
      vars:
        enabled: true
        name: bastion
        instance_type: t3.micro
        inbound_ssh_enabled: true
        associate_public_ip_address: true # deploy to public subnet and associate public IP with instance
        security_group_rules:
          - key         : ssh_us-east-2
            type        : ingress
            from_port   : 22
            to_port     : 22
            protocol    : tcp
            description : Permit core-network to connect from us-east-2
            cidr_blocks : ["10.x.x.x/20"]

the docker installation step is working for this use-case, but it’s in a public subnet

Right - I was just going to say that. I am trying to standup an SSM version of bastion host.

in a private subnet

that should be fine as well, but you may need to update userdata

Is that because I am launching the instance in a private subnet? Any guidance on which parts of the the user data I may need to update?

I suspect it’s because the instance in the private subnet cant install packages listed in userdata. I would suggest adding a flag to disable userdata if it isnt required for your use-case. Or you can add a flag to disable userdata but package all requirements in a custom AMI and then pass that AMI to the component

We don’t have any specific need for custom user data for now. I will disable it through a flag and try it out. Thanks @Dan Miller (Cloud Posse)

@Dan Miller (Cloud Posse) It turns out we do need to install basic tools like psql in the image - so we needed to bring the user data section back in. However, we finally figured out the reason for the issues - the instance did not have a route to internet to download the packages. We updated security group and subnet routes, and all is working as expected now. Thanks for your help!

great! happy to have helped

Thanks @Alex Jurkiewicz - glad to hear it