Learning in Public: AI Dev Tools Zoomcamp - Module 3
Module 3: Test, Containerize, and Deploy an AI-Assisted App
This week we took on several challenges, and to be honest things are starting to get weird... even dangerous.
In short: What I did do, what I did not do, and how a past project architecture decision has led to potential security vulnerabilities.
As previously stated, I have been working through DataTalks.Club's AI Dev Tools Zoomcamp: A free online course that offers a certification at the end. More importantly the course offers the opportunity to build a portfolio with real industry tools and real working software outputs. The essential principle of the course is to use AI tools in the form of coding agents to do the heavy lifting of software development. This course is taught by Alexey Girgorev, and is delivered by video, technical article, and homework feedback. Deliverables so far have been GitHub repository links.
What I did do
I started using tmux.
Tmux is really cool. In the first instance, it allows session persistence. We use the terminal to log into a remote computer to do work. Sometimes this terminal session drops (gets disconnected) because the connection is bad. Sometimes the terminal session drops because the work we are doing takes a really long time, like days or weeks. Using Tmux, the work we are doing "stays alive", and we can nearly always get back into the session of the work we are doing.
We can also connect to the remote computer from different devices, and get into the same remote session to continue our work. For example let's say I start doing some data science work from my desktop computer at home, but doing the actual work on a remote server. And then I need to continue while on the go using the terminal emulator on my phone to connect to that remote server. Then I also need to continue the same session when logged in from the desktop at my work. Tmux allows all of this, and so much more (such as split screen in the terminal).
Ubuntu Linux comes with Tmux pre-installed.
I created a new AWS account
The last AWS account I had was all the way back in 2018, and to be honest, I did very little with it. However, I have already come to the understanding that for the foreseeable future, AWS (which is a huge topic) will be critical to my career path. The sooner I get back to working with AWS, and the more frequently I work with it, the better off I will be when it comes time for that all important technical interview.
I started using Docker again
But...
What we did not do
I did not do enough with Docker
What we did not do in this week's homework assessment is spend enough time hands-on with Docker. The homework assignment is not asking for time spent hands-on with Docker. It is asking for some commands and the name of some Docker Compose resources. Nonetheless, it is life itself that demands time spent hands-on with Docker.
I did not get the updated version of my mini kanban app running in Docker on AWS, but I expect I will need to before completing next week's homework assessment. In any case, the course asks that AWS resources are used very much in an "infrastructure as code" kind of way: set up, then execute, then tear down, using billable resources for as little time as possible. Which is in-and-of-itself and extremely valuable skill.
- How a past project architecture decision has led to potential security vulnerabilities.
For the assignments from the last two course modules, I built the required apps using Claude Code running on the VPS that I rent in th cloud. I also run about a half dozen other websites from this same server.
At the stage of "Install Docker so tests can use testcontainers", Claude Code informed me that installing Docker "adds a new daemon/attack surface to a box serving other live sites." I was alarmed by this information.
It was at this point that I switched over to Claude.ai and asked for a more detailed explanation of the attack surface that Docker adds to the VPS. Claude gave me six major security issues posed by running Docker on a VPS. Each of these issues had multiple technical sub-points.
Claude then went on to suggest other possible options to both meet the homework requirements while not endangering my primary web server (my baby!!!).
Still, even following Claude's workaround suggestions, at a certain point, Docker must be run. So the real solution is to spin up a virtual machine inside AWS, and do the Docker implementation from there. Which I will do -- I promise! -- just maybe not been now, and the time the homework is due at midnight on Monday (tomorrow, as of the writing of the first draft of this post).