We are exploring dockers and trying to find out if dockers provide a way to do the following to eliminate some management overhead with the current approach we are using.
We are looking at something like below:
Have a base template which has Linux OS + App1- Oracle + App2 - Mysql + App3 - Mongodb
Whenever we have a request we should be able to pull a Container out of the base template for a particular App. Ex: Container which has Linux OS + only Oracle app installed. Similarly OS + Mongodb on another container
We have a restriction in having different templates for each of the application, hence we need to have only one master template which can have all apps and pull the containers each time with a particular app only enabled from the base template.
Any pointer on how we can achieve this would be helpful. Can a dockerfile or something else help?
Thanks in advance.
every docker should have one PID. It means we should run one service in one container
You can do this but you should never combine multiple services in one container. It has many downsides and no benefit.
A few downsides:
Can you? Yes. Should you? No.
Layered filesystems mean you can design several images and share common parts of the filesystem. You design your Dockerfile's with the common parts at the top of the Dockerfile or in a common base image. These parts in common should be minimal, you should not have to rebuild app2 because of a change to app1.
Images should be tagged, with a different repository per app, and a different tag for the different builds of each app. The images themselves should contain the binaries, libraries, and other dependencies needed to run the application, but not the configuration or persistent data. Configuration is injected externally with environment variables, command line arguments, configs, secrets, or a read-only volume. And data is almost always saved to a volume or database.
Images do not include the OS, if by OS you include the Linux kernel. Containers share the kernel from the host OS. Do not confuse a container for a VM, they are different, behave differently, and are managed differently.
For mixing and matching different applications with different configurations and databases, this makes the most sense to move to a compose or kubernetes yml file that specifies which images and configurations to deploy. When you change applications, it's not just changing configs for a monolith image, instead, you pull the appropriate image for that specific task.