An asynchronous deployment and operations platform with the aim to better enable simplicity, faster time to delivery, and consistency.
This project is maintained by oshied
A Containerfile and image has been provided allowing operators to run the Server and Client components within a container. While containerization functions and is a great tool for development and test, it is recommended to only run the Server component within a container in production scenarios.
Pre-built Directord images are available on my the major public registries.
$ podman login https://docker.pkg.github.com -u $USERNAME
$ podman pull docker.pkg.github.com/cloudnull/directord/directord:main
$ podman pull quay.io/cloudnull/directord
$ docker pull cloudnull/directord
$ podman build -t directord -f Containerfile
When running Directord in server mode two things need to happen.
Create a volume for the container to access local artifacts.
Create a volume for the client to access the server socket.
$ mkdir -p ~/local/share/directord ~/local/share/directord/etc
$ podman run --hostname directord \
--name directord-server \
--net=host \
--env DIRECTORD_MODE=server \
--volume ${HOME}/local/share/directord/etc:/etc/directord:z \
--volume ${HOME}/local/share/directord:${HOME}/local/share/directord \
--detach \
--user 0 \
directord directord
NOTE: the volume
--volume ${HOME}/local/share/directord:${HOME}/local/share/directord
is specifically using the full path so that the file system structure within the server mirrors that of the local file system. This is important when working with artifacts that are not native to the container. While this path is a share, it could be any mirrored file system path and works perfectly with shared file-systems.
Operators following this example will need to copy content on the local system into
${HOME}/local/share/directord
before running jobs that assume read access to artifacts; such as execCOPY
orADD
jobs and all orchestrations.
Example local client action using a containerized server.
$ directord --socket-path /tmp/directord.sock manage --list-nodes
Because the Directord server runs in an unprivileged container, it can also run in a root-less container. This also means multiple containerized Directord servers can run on a single node, provided
--net=host
isn’t used.
While running clients in a container is functional, their is limited, especially as it pertains to physical infrastructure.
$ podman run --hostname $(hostname)-client \
--name directord-client \
--net=host \
--env DIRECTORD_ZMQ_SERVER_ADDRESS=172.16.27.120 \
--env DIRECTORD_ZMQ_SHARED_KEY=secrete \
--user 0 \
--detach \
directord directord
NOTE: the DIRECTORD_ZMQ_SERVER_ADDRESS environment variable needs to point to the IP address or Domain name of the Directord server.
Both the directord server and client can be run within a container pod. Pod definition files have been provided in the assets directord and can be used to rapidly instantiate infrastructure.
At this time
podman play
does require that the command be run as root.
$ podman play kube pods/pod-directord-server.yaml
$ podman play kube pods/pod-directord-client.yaml
Because the server can be containerized it is possible to run Directord on any
container servicing environment without having to officially install the
application on the local system using conventional packages. Interfacing with a
container can be done in an almost endless number of ways. In the following
example a shell function is used to exec into a running directord-server
container and interface with the client.
function directord() {
podman exec -ti directord-server /directord/bin/directord --socket-path /tmp/directord.sock $@;
}
Running Touchless with the above container invocations still assumes that the working path, where artifacts can be read or written, is
~/directord
.