You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In CI/CD pipelines which use ECS based agents its common to require access to a docker daemon for image builds, docker-compose testing etc.
Following the guidance of this blog post ( https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/ ) the recommended and safe approach is to bind mount the /var/run/docker.sock through to the agent containers. This allows for the agent to run docker commands on the ECS Instance but does run into some issues.
Port conflicts when using docker-compose testing which has exposed host ports
Access to bind mounted volumes between the host and the agent
Security issues with the potential for agents to interact with other docker processes running on the host
To get around some of these, mostly around port conflicts and host access you can create docker in docker side car containers and other workarounds however they generally require privileged containers
The blog post above has been updated to introduce sysbox which creates isolated containers that allow for system level access to resources within the container rather than having to give the container privileged access. To use this service you need to be able to override the runtime to use the sysbox runtime instead of the standard docker runc runtime.
Expected Behavior
When defining a container as part of a task definition the runtime value can be set for the task.
Observed Behavior
Option only available through the nvidia runtime configuration which has a specific purpose
The text was updated successfully, but these errors were encountered:
Summary
Add the ability to set the runtime parameter ( https://docs.docker.com/engine/reference/commandline/dockerd/#docker-runtime-execution-options ) for ECS tasks
Description
In CI/CD pipelines which use ECS based agents its common to require access to a docker daemon for image builds, docker-compose testing etc.
Following the guidance of this blog post ( https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/ ) the recommended and safe approach is to bind mount the
/var/run/docker.sock
through to the agent containers. This allows for the agent to run docker commands on the ECS Instance but does run into some issues.To get around some of these, mostly around port conflicts and host access you can create docker in docker side car containers and other workarounds however they generally require privileged containers
The blog post above has been updated to introduce sysbox which creates isolated containers that allow for system level access to resources within the container rather than having to give the container privileged access. To use this service you need to be able to override the runtime to use the sysbox runtime instead of the standard docker runc runtime.
Expected Behavior
When defining a container as part of a task definition the runtime value can be set for the task.
Observed Behavior
Option only available through the nvidia runtime configuration which has a specific purpose
The text was updated successfully, but these errors were encountered: