External binary sidecar for cloud containers
In an example embodiment, a solution is provided that causes a binary used by an in-memory database application to be deployed in a separate container. The container with the binary may be called a “sidecar” to the container with the in-memory database application. Both containers mount the same path in the hosts shared filesystem to expose the binary to the application. There is no permanent connection between the two containers, and thus the binary can be updated individually without inducing a downtime of the in-memory database application.
1. A system comprising:
at least one hardware processor; and
a computer-readable medium storing instructions that, when executed by the at least one hardware processor, cause the at least one hardware processor to perform operations comprising:
creating a first pod in a container-orchestration system, the first pod containing a reference to an image including an application;
running the first pod on a first host, the running including:
retrieving the image including the application;
launching a first container in a container-based virtualization system;
starting the application; and
mounting a shared volume host path to the first pod;
creating a second pod in a container-orchestration system, the second pod containing a reference to an image including a first version of the binary associated with the application, wherein the application contains one or more calls that, when executed, cause the binary to perform one or more operations;
running the second pod on the first host, the running including:
retrieving the image including the first version of the binary;
launching a second container in the container-based virtualization system; and
mounting the shared volume host path to the second pod, the shared volume host path identifying, to the application, a location of the first version of the binary.
2. The system of claim 1 , wherein the operations further comprise:
creating a third pod in a container-orchestration system, the third pod containing a reference to an image including a second version of the binary associated with the application;
killing the second pod;
running the third pod on the first host, the running including:
retrieving the image including the second version of the binary;
launching a third container in the container-based virtualization system;
mounting the shared volume host path to the third pod; and
updating the shared volume host path to identify, to the application, a location of the second version of the binary.
3. The system of claim 1 , wherein the application is an in-memory database.
4. The system of claim 3 , wherein the binary is an executable to perform backups of the in-memory database.
5. The system of claim 3 , wherein the binary is a driver to connect the in-memory database to a data lake.
6. The system of claim 1 , wherein the container-based virtualization system is Docker.
7. The system of claim 1 , wherein the container-orchestration system is Kubernetes.
8. A method comprising:
creating a first pod in a container-orchestration system, the first pod containing a reference to an image including an application;
running the first pod on a first host, the running including:
retrieving the image including the application;
launching a first container in a container-based virtualization system;
starting the application; and
mounting a shared volume host path to the first pod;
creating a second pod in a container-orchestration system, the second pod containing a reference to an image including a first version of the binary associated with the application, wherein the application contains one or more calls that, when executed, cause the binary to perform one or more operations;
running the second pod on the first host, the running including:
retrieving the image including the first version of the binary;
launching a second container in the container-based virtualization system; and
mounting the shared volume host path to the second pod, the shared volume host path identifying, to the application, a location of the first version of the binary.
9. The method of claim 8 , wherein the operations further comprise:
creating a third pod in a container-orchestration system, the third pod containing a reference to an image including a second version of the binary associated with the application;
killing the second pod;
running the third pod on the first host, the running including:
retrieving the image including the second version of the binary;
launching a third container in the container-based virtualization system;
mounting the shared volume host path to the third pod; and
updating the shared volume host path to identify, to the application, a location of the second version of the binary.
10. The method of claim 8 , wherein the application is an in-memory database.
11. The method of claim 10 , wherein the binary is an executable to perform backups of the in-memory database.
12. The method of claim 10 , wherein the binary is a driver to connect the in-memory database to a data lake.
13. The method of claim 8 , wherein the container-based virtualization system is Docker.
14. The method of claim 8 , wherein the container-orchestration system is Kubernetes.
15. A non-transitory machine-readable medium storing instructions which, when executed by one or more processors, cause the one or more processors to perform operations comprising:
creating a first pod in a container-orchestration system, the first pod containing a reference to an image including an application;
running the first pod on a first host, the running including:
retrieving the image including the application;
launching a first container in a container-based virtualization system;
starting the application; and
mounting a shared volume host path to the first pod;
creating a second pod in a container-orchestration system, the second pod containing a reference to an image including a first version of the binary associated with the application, wherein the application contains one or more calls that, when executed, cause the binary to perform one or more operations;
running the second pod on the first host, the running including:
retrieving the image including the first version of the binary;
launching a second container in the container-based virtualization system; and
mounting the shared volume host path to the second pod, the shared volume host path identifying, to the application, a location of the first version of the binary.
16. The non-transitory machine-readable medium of claim 15 , wherein the operations further comprise:
creating a third pod in a container-orchestration system, the third pod containing a reference to an image including a second version of the binary associated with the application;
killing the second pod;
running the third pod on the first host, the running including:
retrieving the image including the second version of the binary;
launching a third container in the container-based virtualization system;
mounting the shared volume host path to the third pod; and
updating the shared volume host path to identify, to the application, a location of the second version of the binary.
17. The non-transitory machine-readable medium of claim 15 , wherein the application is an in-memory database.
18. The non-transitory machine-readable medium of claim 17 , wherein the binary is an executable to perform backups of the in-memory database.
19. The non-transitory machine-readable medium of claim 17 , wherein the binary is a driver to connect the in-memory database to a data lake.
20. The non-transitory machine-readable medium of claim 15 , wherein the container-based virtualization system is Docker.