A Container resource in gopaddle contains the build time and the run time attributes of a Docker Container. A container can be created from one of these sources:
Existing Docker Image: Requires a registry from where to pull the Docker Image.
Docker Project from a Source Control Repository that contains a Dockerfile: Dockerfile must be present in the root directory of the Docker project. Requires a build environment to build the container and a Registry (Distribution Registry) to push the newly built Docker Image.
Source Control Project from a Source Control Repository: Requires a build environment to build the container and a Registry (Distribution Registry) to push the newly built Docker Image.
To specify the build environment, the Distribution Registry and/or the build scripts, you must create the container and add build scripts to it. Check the Creating a Container article to create a new Container and the Adding Build Scripts article for more information.
Types of Containers:
Default Containers : These containers are deployed as long running processes.
Init Containers: These containers are deployed as side cars to Default Containers to perform certain initialisation tasks before starting the Default Containers.
Both Default and Init Containers may or may not expose a network port. If they do not expose a network port they are called Headless Containers.
Sidecars are a collection of containers that are deployed together. They share CPU/Mem/Network resources. They communicate with each other by either using common directories called Shared Folders or via the localhost and port number.
One of the popular use cases of side cars is to deploy log management solutions like fluentd containers along with the main container. While the main container writes logs to the Shared Folder, the fluentd container can read the logs from the Shared Folder and push the logs to the ElastiSearch.
Containers are version controlled when some of the key attributes are changed. This ensures right update strategies are followed while updating a running container. Updating a container build script or creating a new build, does not require a new version of the container. However changes like ports and data folders need to be saved as new version of the container so that right update strategies are available while updating the container.