It's been a while to have something dockerized and deploy it in a production ready environment. To shape up my DevOp skills, I will try to set up a new ECS environment and blog what I did along the way. The application I am working on is built on top of the latest Nuxt JS. So, If you happened to follow something similar path, hope you find this somewhat helpful to better understand an option that I came up with.

Things that I have on my mind

1. Build a front-end universal app using the latest NuxtJS and Vuetify and some other goodies I can think of.
2. Build a back-end API using the latest Laravel 6
3. Deploy the front-end to AWS ECS/Fargate
4. Deploy the back-end to AWS EB

What I'd like to address this time is #3. The rest of the list have been addressed already and I've got solid work experience on the topics. When you have your own Docker container ready to use, you can deploy it to AWS ECS within a short period of time. you can even deploy it to AWS Elastic Beanstalk. But, ECS/Fargate route is what I've chosen to go with this time. To have a basic setup, read the article below along. Its step by step explanation is easy to follow.

https://itnext.io/run-your-containers-on-aws-fargate-c2d4f6a47fda

As with many other things in IT, however, there're a lot more to come. This one is no exception. Take a look at the following article written specifically on how to deploy NuxtJS app to ECS. The writer mentioned about runtime environment variable injection for the sake of security.

https://melvinkoh.me/dockerizing-and-deploying-nuxtjs-ssr-apps-to-aws-ecs-ck1egcwoi00dmjfs1w2cr3shq

With my current project, I've set up the following 5 variables in AWS System Manager Parameter Store. As you can see I added a prefix (prod-) to all of 'em.

So that I can easily write a rule to have an access right in the following fashion.

https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-access.html

In case you wonder, my IAM ecs-task-execution-role has an inline policy like:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:DescribeParameters"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:GetParameters"
            ],
            "Resource": [
                "arn:aws:ssm:ap-northeast-2:123456000000:parameter/prod-*"
            ]
        }
    ]
}

But then, I confronted unexpected runtime environment variable issue with NuxtJS. A funny thing is that I've got no issues whatsoever on my local PC. But, NuxtJS didn't read the run-time environment variables in the production environment. WTF?! After further investigation,

https://github.com/nuxt/nuxt.js/issues/5100

I found the issue thread in its GitHub repo. As a workaround I was able to get around the problem by using samtgarson/nuxt-env and adding additional logic to my code base. Now, I can inject run-time environment variables with the package. As described in several posts in the thread, either ctx.app.$env.XXX or this.$env.XXX works depending on the usage.