At DNX we are committed to democratizing cloud technologies. Part of our plan is to develop and release to the public a large part of what we use with our clients.
After a little more than 1 year, this strategy translated into:
And here’s our update of that happened in the last few months.
DNX One — Updates
One is how we call our platform deployed on top of AWS. It’s a set of terraform stacks and modules to set up our client’s AWS accounts following well-architected concepts and with efficiency and cost in mind.
For this update, we focused on the themes below.
Monitoring
Added new alarms to the stack:
[terraform-aws-ecs-app]The alarm on the number for healthy tasks less than 2[terraform-aws-ecs]The alarm on EFS credits running low[terraform-aws-ecs-app-front]Renaming alarm for 500 errors to be more descriptive of the actual metric
With these above features, we are improving the AWS Operational experience across customers, by adding crucial monitoring alarms to avoid services disruption.
Blue-Green Deployments
We improved our ECS modules to support blue-green with a manual cutover. This means the application can be deployed to production and be accessible on a different URL for validation, without affecting the live application. And then, the decision between cutting over or discarding can be made. That improves the continuous delivery model that we apply across DNX clients, allowing zero downtime and a better way to test new features without affecting real users.
[terraform-aws-ecs-app]Removing the blue domain as access to blue will be done using the test listener in the ALB; Changes to allow blue-green with manual cutover[terraform-aws-ecs]Blue-green using test listener; Allow real blue-green with manual cutover
Cost Savings
We implemented in our stack, for non-production environments, an option to power off instances at night. This technique is also covered in a blog post.
[terraform-aws-ecs]Scheduler to scale ASG to zero outside business hours[terraform-aws-rds-scheduler]New module
There’s also a new module called terraform-aws-billing that helps customers track their AWS bill with alarms and budgets, sending alerts directly to their Slack using AWS Chatbot.
Security
To help with compliance, we released a new terraform module that adds alarms on CloudTrail events: terraform-aws-security-baseline.
The new security baseline module enables HIPAA customers to follow CIS Amazon Web Services Foundations.
Other important updates
[terraform-aws-ecs]Adding optional internal ALB for private APIs
Under development
one-cli
As an effort to simplify deployments of infrastructure-as-code and applications, we started developing a CLI called one.
The goal is to provide a layer of PaaS on top of AWS and reduce the complexity of scripts inside the client’s code repositories.
You can track the progress at https://github.com/DNXLabs/one-cli
For a snapshot of all our open-source code can be found at: https://modules.dnx.one/
Fill up the repository name and hit create.
You can also check our Terraform stack which will allow you to create a repository using infrastructure as code:
But let’s keep in mind the security layer that I mentioned. One cool feature of the AWS ECR service is the possibility of scanning the image pushed at your will.
Ok, inspecting all images pushed manually is not what we want. It’s possible to enable the scan-on-push feature during the repository creation and edit a pre-existent repository and enable it.
Our Terraform stack provides the scanning-on-push feature enabled by default:
After pushing an image to your docker registry, the column Vulnerabilities will appear in your ECR for each new image:
Checking the vulnerabilities details:
Now that we can see the vulnerabilities, what else can we do?
Let’s say that you (and everybody else concerned about security) don’t want to deploy this image to your environments (Dev, QA, Homolog/Staging, and definitely not to Prod).
You can use the script below in your pipeline. The script will stop the deployment if it finds a security vulnerability.
If you want to stop the deployments of CRITICAL vulnerable images only, you just need to set the environment variable SEVERITY to CRITICAL.
If you want to be more strict, you can set more severity levels. To do it, you need to set that environment variable as a list, e.g: SEVERITY = “CRITICAL HIGH”. The meaning of the list is simple. If you set a lower severity level and your image has greater level breaches, the deployment will go on.
Go ahead and add the script one step before you deploy a new image to your environment:
Conclusion
It’s a simple solution that can avoid a major vulnerability to go forward to your production environment. Using the AWS tools on your behalf could save you from a few headaches.
At DNX Solutions, we work to bring a better cloud and application experience for digital-native companies in Australia. Our current focus areas are AWS, Well-Architected Solutions, Containers, ECS, Kubernetes, Continuous Integration/Continuous Delivery and Service Mesh. We are always hiring cloud engineers for our Sydney office, focusing on cloud-native concepts. Check our open-source projects at https://github.com/DNXLabs and follow us on Twitter, Linkedin or Facebook.
No spam - just releases, updates, and tech information.Stay informed on the latest
insights and tech-updates
