At some point in time, your development is going to shift from traditional, monolithic applications to microservices. That means containers. The world of container development is quite a bit different than what you might be used to, which means a lot of the old best practices no longer apply.
So if you’re looking at a shift away from standard application development, what do you do? You learn as fast as you can. And given how fast the development world is evolving these days, that pace has reached a breakneck speed. So you have to learn best practices quickly, or you run the risk of either being pushed out of the game, or constantly deploying applications that either don’t work, aren’t reliable, can’t scale, or are far too insecure to be used in an enterprise environment.
What are some of the best practices you should already be up to speed on for container development? Let’s take a look at some of those which are more immediate and can be implemented from the very beginning of your journey.
Use Stable Images From Known Entities
This is at the top of the list, simply because it has become one of the single most important issues facing container security. Everything you develop in a containerized world starts with an image. You might build your own from scratch or you might take the quick route and pull an image from, say, Docker Hub. Should you go the third-party route, you must always only use stable images from known entities.
Say, for example, you want to base a container deployment on the latest Python image. If you search Docker Hub, you’ll find plenty of images for Python, but only one official image from the actual Python developers. That’s the image you should use. Every image that comes from an official entity will be tagged as such. It’s important that you only ever use those images. Don’t pull down an image from an unknown source, because you never know what it might contain.
Keep Your Images Small
You might be tempted to form your containers on an image that includes several bells and whistles. Keep this in mind: The bigger the image, the bigger your container. If you base all of those containers on larger images when you’re deploying an application that includes a number of moving parts, not only are you introducing unnecessary services, you risk racking up a significantly higher cloud hosting bill.
Remember, the idea behind containerization is to achieve massive scalability at reduced prices. So deploying containers based on large images defeats that purpose.
Don’t do that. Always use the smallest (official) image you can find. And if you can’t find an official image small enough, create your own. On top of which, with a larger image, the attack plan can grow exponentially.
Keep it small.
Use Persistent Data
You should avoid storing data within a container’s storage layer. Why? Two reasons: Storage and accessibility. Consider this: If you were to store data within a container’s storage layer, that container is going to grow exponentially. That’s not all. Should the container go down, the data will no longer be accessible. Instead, you should store your data in persistent volumes.
By using volumes you ensure the size of the containers won’t grow as more data is collected, and the data stored can be accessible by numerous containers.
Employ CI/CD for Testing and Deployment
You’re going to need a lot of testing. And deployment will be a constant affair. Remember, when you containerize an application, the goal is automation. You don’t want to slow down the deployment time by having to manually test and re-deploy everything. Instead, adopt a Continuous Integration/Continuous Deployment (CI/CD) approach.
With CI/CD the goal is to automate as much as possible. Once you’ve employed CI/CD for testing and deployment, you’ll find everything works so much more efficiently.
Tag Container Images Smartly
As you create your own images (or modify those you pull down), you’ll have to tag them before they can be pushed back to your repositories. When you tag those images, make sure you do so smartly. Don’t just tag an image with “latest” or the date. You might have rolled in a specific feature to an image or created an image for a certain purpose.
Make sure you tag those images in such a way that you’ll always know their purpose.
Consider Security at Every Step
With container development, security starts at square one and never stops. This is especially so when your goal is automation. At that point, you should consider security as a circle that runs around every aspect of your deployment.
Security starts with the base images, runs through your container manifests, checks in on your DevOps, GitOps, and automation tools, follows through the deployment, and circles back to the repositories housing your code. If you look at security as a never-ending component, one that must follow the container from start to finish, you’ll find those deployments are worth using.
Just remember, security in container development never rests.
One App Per Container
Although you can deploy a single container that houses every app needed for a service, you shouldn’t. Why? The biggest reason is that single application containers are easier to scale. And since scalability is one of the primary goals of containerization, it’s a no-brainer.
Scalability is made possible because a cluster manager can deploy more containers when needed. For example, if your application only requires more instances of a database to scale, if you’ve rolled that database into a container with other applications, the scaling will include those other apps, which isn’t efficient.
Single application containers are also much easier to build and test.
Conclusion
If you start your container development journey with these best practices, you’ll be off on the right foot. Of course, there are always more best practices to be had, some of which will be dictated by the project at hand. But, in general, what you see here should serve you in most container deployments.
