Docker Certified Associate Exam Preparation Guide(evalle.github.io)
evalle.github.io
Docker Certified Associate Exam Preparation Guide
https://evalle.github.io/DCA/
17 comments
Dead in the water.
I had to read to whole thing twice to convince myself that it wasn't a joke.
BTW, I don't understand why there's a need for Docker certification in the first place.
BTW, I don't understand why there's a need for Docker certification in the first place.
Because they have to make money somehow. They took $300M in VC funding. Their product is open source and was subsumed by Kubernetes.
And podman seems to be better than docker in every respect, and it doesn't require special permissions.
I'm not an expert in this area. Are there any things docker does that podman cannot? Also how much code do do they share? (as in libraries used by both)
I'm not an expert in this area. Are there any things docker does that podman cannot? Also how much code do do they share? (as in libraries used by both)
[deleted]
For starters, Podman doesn't support anything like Docker Compose ( https://docs.docker.com/compose/ ) out of the box, which makes it harder to orchestrate deployments that need multiple containers locally.
There is podman-compose as a drop-in ( https://github.com/containers/podman-compose ), but last i checked it wasn't supported by or developed by RedHat themselves, hence no first-party support. In addition to that, the feature parity just isn't there.
Also, there is no docker.sock, which tools like Portainer ( https://www.portainer.io/ ) need to interface with Docker, hence no control web apps and other tools are available for Podman.
Besides that, there is also Docker Swarm ( https://docs.docker.com/engine/swarm/ ), a lightweight orchestrator which can be a simpler alternative to Kubernetes in smaller and more resource constrained environments, which isn't available in Podman. In addition to that, Docker Swarm's deployment format is also extremely similar to the Docker Compose one (with additional functionality added for multi node clusters), which allowed for getting started with container orchestration in a more simple fashion.
If you're in a Kubernetes shop and simply need something for Kubernetes to interface with, then containerd (which Docker uses internally) and Podman are largely comparable.
In other circumstances, Podman doesn't have complete feature parity with Docker, despite popular claims and despite its architectural improvements.
There is podman-compose as a drop-in ( https://github.com/containers/podman-compose ), but last i checked it wasn't supported by or developed by RedHat themselves, hence no first-party support. In addition to that, the feature parity just isn't there.
Also, there is no docker.sock, which tools like Portainer ( https://www.portainer.io/ ) need to interface with Docker, hence no control web apps and other tools are available for Podman.
Besides that, there is also Docker Swarm ( https://docs.docker.com/engine/swarm/ ), a lightweight orchestrator which can be a simpler alternative to Kubernetes in smaller and more resource constrained environments, which isn't available in Podman. In addition to that, Docker Swarm's deployment format is also extremely similar to the Docker Compose one (with additional functionality added for multi node clusters), which allowed for getting started with container orchestration in a more simple fashion.
If you're in a Kubernetes shop and simply need something for Kubernetes to interface with, then containerd (which Docker uses internally) and Podman are largely comparable.
In other circumstances, Podman doesn't have complete feature parity with Docker, despite popular claims and despite its architectural improvements.
Disclaimer: I work for Red Hat which is the main force behind Podman
I mostly agree, however I don't think saying that Podman lacking a docker.sock is a lack of feature parity, since that's actually considered a feature of Podman. The daemon model that Docker uses has security implications that are non-trivial. Podman chooses not to be a daemon by choice. There is a sister project called CRI-O that has a daemon which will get you the daemonized portion if that's what you want. It has a similar API and a CLI called crictl to drive it. It's not widely used outside of Kubernetes, but it is available if you want it. If you're trying to compare apples to apples, it should be docker vs podman/cri-o, not docker vs podman.
Podman also has some features that Docker does not have, such as the ability to create, run, and export Pods (same YAML definition as Kubernetes, which is mighty convenient).
I used to use docker-compose all the time, but I've found I largely don't need it anymore since I can put the various dev services into the same Pod. This is even more convenient since from every container you can just reference "localhost" since the Pod shares a network namespace between containers. It's not a perfect solution though, and certainly isn't a drop-in for docker-compose (although nobody working on Podman has claimed it is, either).
All that said Docker still has it's place. There are tools that need the docker sock in order to work. One that I wrote (called Dory[1]) is a good example of one that won't work on Podman/CRI-O without significant work.
[1]: https://github.com/freedomben/dory
I mostly agree, however I don't think saying that Podman lacking a docker.sock is a lack of feature parity, since that's actually considered a feature of Podman. The daemon model that Docker uses has security implications that are non-trivial. Podman chooses not to be a daemon by choice. There is a sister project called CRI-O that has a daemon which will get you the daemonized portion if that's what you want. It has a similar API and a CLI called crictl to drive it. It's not widely used outside of Kubernetes, but it is available if you want it. If you're trying to compare apples to apples, it should be docker vs podman/cri-o, not docker vs podman.
Podman also has some features that Docker does not have, such as the ability to create, run, and export Pods (same YAML definition as Kubernetes, which is mighty convenient).
I used to use docker-compose all the time, but I've found I largely don't need it anymore since I can put the various dev services into the same Pod. This is even more convenient since from every container you can just reference "localhost" since the Pod shares a network namespace between containers. It's not a perfect solution though, and certainly isn't a drop-in for docker-compose (although nobody working on Podman has claimed it is, either).
All that said Docker still has it's place. There are tools that need the docker sock in order to work. One that I wrote (called Dory[1]) is a good example of one that won't work on Podman/CRI-O without significant work.
[1]: https://github.com/freedomben/dory
"best viewed with microsoft internet explorer". How the turns have tabled...
It makes sense though.
Even though these kinds of certified exams are taken online, it is monitored by a human proctor (from a partner exam platform like Pearson). The proctor will check your environment like webcam, mic, the number of windows opened, running processes, the number of connected displays etc.
Don't expect the proctor is tech enthusiastic enough to understand various kinds of Linux Desktop environments.
Even though these kinds of certified exams are taken online, it is monitored by a human proctor (from a partner exam platform like Pearson). The proctor will check your environment like webcam, mic, the number of windows opened, running processes, the number of connected displays etc.
Don't expect the proctor is tech enthusiastic enough to understand various kinds of Linux Desktop environments.
I took the exam a while ago, biggest BS exam I ever took. It tries to figger out if you know the correct flags and syntax for commands.
> It costs 195 USD or 175 EUR;
A cost of 1/7 of an European bachelor degree (France rates used) for a certification recognized by nobody(?) is very very expensive.
A cost of 1/7 of an European bachelor degree (France rates used) for a certification recognized by nobody(?) is very very expensive.
That's true for all these tech certificates. Getting a university degree is always better value for your money in Europe.
The only thing that drives value for these kind of certificates is enterprise consulting.
Many RFPs and consulting partners do gatekeeping where certain deals or access to products is only available when those doing project delivery have a certain amount of certified people on the company or delivery team.
So in these cases, one can have a degre from number one top university, still won't win the project deal or be allowed into the products developer portal.
Many RFPs and consulting partners do gatekeeping where certain deals or access to products is only available when those doing project delivery have a certain amount of certified people on the company or delivery team.
So in these cases, one can have a degre from number one top university, still won't win the project deal or be allowed into the products developer portal.
Some companies list certification requirements as a plus to their job description. While I don't care much about certificate/badge - it's a good motivator to learn beyond everyday work.
Certifications are a bit wasteful in Europe. It's better to spend your time on other things.
Depends on the cert how valuable it is. Some of the RedHat exams are very much respected in the industry and give the credentialized person a lot of options on where and what they work on.