MLH Fellowship Insider: Week 6
--
This summer, I am doing the Major League Hacking (MLH) Site Reliability Engineering Fellowship which is run in partnership with Meta. The MLH Fellowship is a 12 week technical program where fellows complete an educational curriculum, build open source software, and receive mentorship from professional engineers to learn more about the world of site reliability engineering. I wanted to share my experience as I go through the program to provide more insights for anyone interested in applying!
Week 6
Week 6 begins with a question: “Has it ever happened to you that you create an application which runs like a charm on your machine but when you pass it on to someone else, for some reason it doesn’t quite work on their machine?” For me, the answer is yes. And the solution, I learned, is using containers.
Containers are a way to virtualize an operating system. They do this by containing all the dependencies required by a software project. This keeps the dependencies isolated allowing you to run the project on multiple environments (e.g., both on your local laptop and the cloud). Containers are different and more “lightweight” than virtual machines (discussed in week 2) because they provide OS virtualization without needing to virtualize hardware (the case for virtual machines).
In the fellowship, we used the Docker platform to create containers for running our portfolio websites. To use Docker, we wrote a Dockerfile and docker-compose.yml file to contain all the applications and dependencies needed by our websites. These were then used to build Docker images which defined three containers: (1) Flask server, (2) Database server, and (3) Nginx reverse proxy.
Three separate containers were defined for each component rather than one container for all the components (a concept called “container orchestration”) because it ensured that an update to one part of the project did not force an unwanted container rebuild on another part. For example, if we had everything (including the database) defined in one container, rebuilding that container after an application update would cause all the stored data to be lost. Container orchestration avoids this issue.
The last update to discuss is the Nginx container mentioned above. Nginx is a ready-made docker image that serves as a reverse proxy in front of the web server. In our websites, it is used specifically for SSL termination (i.e., decrypting and encrypting traffic before it goes to the web server). We created a container for it by adding its definition to our docker-compose file.
Now our websites are being run through containers! Here is a screenshot of my website’s timeline page that can be accessed through the browser!
