First blog post is going to be about the wonders of containers and how that helps us in numerous ways when it comes to simplifying DevOps.
Back when I was in university, containers were only a pipe dream (certainly not used in InfoSec Lectures!). We made use of virtual computers in our labs in order to have the tools required to complete the tasks at hand. Which usually were something along the lines of “how do we break this website, is it vulnerable to SQL injection?”
Turns out I'm still quite apt at breaking websites!
A few years into being a professional software engineer after university, the CTO put us on these new things called Docker containers. "It's going to save us all the leg work of installing our software and dependencies on different machines."
It certainly did - we started on some of our Rails apps and improved them bit by bit.
The first aim was to improve the developer on-boarding. Then it was to be able to move the Rails app easily to another server.
Today we utilise docker-compose to manage numerous containers which interface with each other. Having to do this manually would have been a right old pain, and we can move it between servers relatively easily.
Having containers enables us to have a CI/CD pipeline - using Github Actions to run our automated tests and a self-hosted runner to deploy on an air-gapped network.
In the future, we will be experimenting further with scalable container solutions (think AWS Fargate etc) - to see if it can help bring further service improvements to our offerings.
Thanks for reading!
Back when I was in university, containers were only a pipe dream (certainly not used in InfoSec Lectures!). We made use of virtual computers in our labs in order to have the tools required to complete the tasks at hand. Which usually were something along the lines of “how do we break this website, is it vulnerable to SQL injection?”
Turns out I'm still quite apt at breaking websites!
A few years into being a professional software engineer after university, the CTO put us on these new things called Docker containers. "It's going to save us all the leg work of installing our software and dependencies on different machines."
It certainly did - we started on some of our Rails apps and improved them bit by bit.
The first aim was to improve the developer on-boarding. Then it was to be able to move the Rails app easily to another server.
Today we utilise docker-compose to manage numerous containers which interface with each other. Having to do this manually would have been a right old pain, and we can move it between servers relatively easily.
Having containers enables us to have a CI/CD pipeline - using Github Actions to run our automated tests and a self-hosted runner to deploy on an air-gapped network.
In the future, we will be experimenting further with scalable container solutions (think AWS Fargate etc) - to see if it can help bring further service improvements to our offerings.
Thanks for reading!