Balance innovation and agility with security and compliance
risks using a 3-step process across all cloud infrastructure.
Step up business agility without compromising
security or compliance
Everything you need to become a Kubernetes expert.
Always for free!
Everything you need to know about Magalix
culture and much more
Switching from traditional Vms to containerized applications can bring major upgrades in efficiency and reliability. But if you handle your containers incorrectly, you’ll be throwing all those benefits out the window – and frustrating your users in the process!
Here are three of the most common mistakes many organizations make when they implement Docker containers for the first time.
While containers are great at storing non-sensitive data for individual sessions, they’re not designed to store data that needs to persist across sessions, or any information that may pose a security risk. In fact, if you store any sensitive data within the container itself, you run the risk of losing that data when that container stops – and if you store secrets such as passwords using environment variables or container registries, you run a significant risk of being compromised, as Vine was in 2016.
Instead of storing your containerized data locally, it’s always a better idea to keep secrets, critical data – and in fact, all data other than container images and temporary files – in the cloud, and fetch it via SSH on an as-needed basis. That’s the only surefire way to keep private information secure, while also keeping your important data is safe.
One common Docker newbie mistake is to treat a container as if it’s a conventional Linux environment, and practically set up an entire OS inside it. Even in less extreme cases, many novices make the mistake of hosting many (seemingly) necessary services inside the same container. But this is a major mistake, because every service increases your security vulnerability.
As Docker’s best practices document explains, it’s best to stick to the rule of “one process per container.” Even if it’s sometimes necessary to run two or more processes in the same container – for example, instances of cron and Syslog – it’s better to let a baseline Linux image handle those services, for you.
It won’t take long to notice problems with the Dockerfiles build-cache, because your container images will suddenly start taking a very long time to build. If you’re using behaviors like ADD, VOLUMES or RUN in the wrong places, those may be invalidating your cache. It’s also important to keep in mind that Dockerfile execution happens sequentially, so changes can deprecate future caches.
To keep your cache reasonably sized without losing critical data, try grouping your RUN shell sequences together according to type, and handling cache orders manually rather than automatically. Purging the cache is only a last-resort measure, but a bit of careful selective invalidation can help you regain control of troublesome cache volumes when necessary.
Empower developers to delivery secure and compliant software with trusted application delivery and policy as code. Learn more.
Automate your deployments with continuous application delivery and GitOps. Read this blog to learn more.