conlink 2.0.0

package/README.md

@@ -0,0 +1,485 @@
+# conlink: Declarative Low-Level Networking for Containers
+
+Create (layer 2 and layer 3) networking between containers using
+a declarative configuration.
+
+## Prerequisites
+
+* docker-compose version 1.25.4 or later.
+* `openvswitch` kernel module loaded on the host
+* `geneve` (and/or `vxlan`) kernel module loaded on the host (only
+  needed for `test5-geneve-compose` example)
+
+## Usage Notes
+
+### Asynchronous startup
+
+The conlink managed container links are created after the main process
+in the container starts executing. This is different from normal
+docker behavior where the interfaces are created and configured before
+the main process starts. This means the interfaces for those
+links will not be immediately present and the container process will
+need to account for this asynchronous interface behavior. The `node`
+service in `examples/test2-compose.yaml` shows a simple example of
+a container command that will wait for an interface to appear before
+continuing with another command.
+
+### System Capabilities/Permissions
+
+The conlink container needs to have a superset of the network related
+system capabilities of the containers that it will connect to. At
+a minimum `SYS_ADMIN` and `NET_ADMIN` are required but depending on
+what the other containers require then those additional capabilities
+will also be required for the conlink container. In particular, if the
+container uses systemd, then it will likely use `SYS_NICE` and
+`NET_BROADCAST` and conlink will likewise need those capabilities.
+
+## Network Configuration Syntax
+
+Network configuration can either be loaded directly from configuration
+files using the `--network-config` option or it can be loaded from
+`x-network` properties contained in docker-compose files using the
+`--compose-file`. Multiple of each option may be specified and all the
+network configuration will be merged into a final network
+configuration.
+
+The network configuration can have three top level keys: `links`,
+`tunnels`, and `commands`.
+
+### Links
+
+Each link defintion specifies an interface that will be configured in
+a container. Most types have some sort of connection to either the
+conlink/network container or the host network namespace. For example,
+"veth" type links always have their peer end connected to a bridge in
+the conlink/network container and vlan types are children of physical
+interfaces in the host.
+
+The following table describes the link properties:
+
+| property  | link types | format     | default | description              |
+|-----------|------------|------------|---------|--------------------------|
+| type      | *          | string 1   | veth    | link/interface type      |
+| service   | *          | string     | 2       | compose service          |
+| container | *          | string     |         | container name           |
+| bridge    | veth       | string     |         | conlink bridge / domain  |
+| outer-dev | not dummy  | string[15] |         | conlink/host intf name   |
+| dev       | *          | string[15] | eth0    | container intf name      |
+| ip        | *          | CIDR       |         | IP CIDR (index offset)   |
+| mac       | 3          | MAC        |         | MAC addr (index offset)  |
+| mtu       | *          | number 4   | 9000    | intf MTU                 |
+| route     | *          | string     |         | ip route add args        |
+| nat       | *          | IP         |         | DNAT/SNAT to IP          |
+| netem     | *          | string     |         | tc qdisc NetEm options   |
+| mode      | 5          | IP         |         | virt intf mode           |
+| vlanid    | vlan       | IP         |         | VLAN ID                  |
+
+- 1 - veth, dummy, vlan, ipvlan, macvlan, ipvtap, macvtap
+- 2 - defaults to outer compose service
+- 3 - not ipvlan/ipvtap
+- 4 - max MTU of parent device for \*vlan, \*vtap types
+- 5 - macvlan, macvtap, ipvlan, ipvtap
+
+Each link has a 'type' key that defaults to "veth" and each link
+definition must also have either a `service` key or a `container` key.
+If the link is defined in the service of a compose file then the value
+of `service` will default to the name of that service.
+
+The `container` key is a fully qualified container name that this link
+will apply to. The `service` key is the name of a docker-compose
+service that this link applies to. In the case of a `service` link, if
+more than one replica is started for that service, then the mac, and
+ip values in the link definition will be incremented by the service
+index - 1.
+
+All link definitions support the following optional properties: dev,
+ip, mtu, route, nat, netem. If dev is not specified then it will
+default to "eth0".  For `*vlan` type interfaces, mtu cannot be larger
+than the MTU of the parent (outer-dev) device.
+
+For the `netem` property, refer to the `netem` man page. The `OPTIONS`
+grammar defines the valid strings for the `netem` property.
+
+### Tunnels
+
+Tunnels links/interfaces will be created and attached to the specified
+bridge. Any containers with links to the same bridge will share
+a broadcast domain with the tunnel link.
+
+The following table describes the tunnel properties:
+
+| property  | format  | description                |
+|-----------|---------|----------------------------|
+| type      | string  | geneve or vxlan            |
+| bridge    | string  | conlink bridge / domain    |
+| remote    | IP      | remote host addr           |
+| vni       | number  | Virtual Network Identifier |
+| netem     | string  | tc qdisc NetEm options     |
+
+Each tunnel definition must have the keys: type, bridge, remote, and
+vni. The netem optional property also applies to tunnel interfaces.
+
+### Commands
+
+Commands will be executed in parallel within the matching container
+once all links are succesfully configured for that container.
+
+The following table describes the command properties:
+
+| property  | format           | description                |
+|-----------|------------------|----------------------------|
+| service   | string           | compose service            |
+| container | string           | container name             |
+| command   | array or string  | command or shell string    |
+
+Each command defintion must have a `command` key and either
+a `service` or `container` key. The `service` and `container` keys are
+defined the same as for link properties.
+
+If the `command` value is an array then the command and arguments will
+be executed directly. If the `command` is a string then the string
+will be wrapped in `sh -c STRING` for execution.
+
+
+## Examples
+
+The examples below require a conlink docker image. Build the image for
+both docker and podman like this:
+
+```
+docker build -t conlink .
+podman build -t conlink .
+```
+
+### test1: compose file with embedded network config
+
+Start the test1 compose configuration:
+
+```
+docker-compose -f examples/test1-compose.yaml up --build --force-recreate
+```
+
+From h1 ping the address of h3 (routed via the r0 container):
+
+```
+docker-compose -f examples/test1-compose.yaml exec h1 ping 10.0.0.100
+```
+
+
+### test2: compose file with separate network config and live scaling
+
+Start the test2 compose configuration:
+
+```
+docker-compose -f examples/test2-compose.yaml up -d --build --force-recreate
+```
+
+From the first node ping the second:
+
+```
+docker-compose -f examples/test2-compose.yaml exec --index 1 node ping 10.0.1.2
+```
+
+From the second node ping an address in the internet service:
+
+```
+docker-compose -f examples/test2-compose.yaml exec --index 2 node ping 8.8.8.8
+```
+
+Scale the nodes from 2 to 5 and then ping from first node from the fifth:
+
+```
+docker-compose -f examples/test2-compose.yaml up -d --scale node=5
+docker-compose -f examples/test2-compose.yaml exec --index 5 node ping 10.0.1.1
+```
+
+
+### test3: network config file only (no compose) and variable templating
+
+#### test3 with docker
+
+Start two containers named `ZZZ_node_1` and `ZZZ_node_2`.
+
+```
+docker run --name=ZZZ_node_1 --rm -d --network none alpine sleep 864000
+docker run --name=ZZZ_node_2 --rm -d --network none alpine sleep 864000
+```
+
+Start the conlink container `ZZZ_network` that will setup a network
+configuration that is connected to the other containers:
+
+```
+./conlink-start.sh -v --mode docker --host-mode docker --network-file examples/test3-network.yaml -- --name ZZZ_network --rm -e NODE_NAME_1=ZZZ_node_1 -e NODE_NAME_2=ZZZ_node_2
+```
+
+In a separate terminal, ping the node 2 from node 1.
+
+```
+docker exec -it ZZZ_node_1 ping 10.0.1.2
+```
+
+#### test3 with rootless podman
+
+Same as test3 but using rootless podman instead
+
+Start two containers named `ZZZ_node_1` and `ZZZ_node_2`.
+
+```
+podman run --name=ZZZ_node_1 --rm -d --network none alpine sleep 864000
+podman run --name=ZZZ_node_2 --rm -d --network none alpine sleep 864000
+```
+
+Start the conlink container `ZZZ_network` that will setup a network
+configuration that is connected to the other containers:
+
+```
+./conlink-start.sh -v --mode podman --host-mode podman --network-file examples/test3-network.yaml -- --name ZZZ_network --rm -e NODE_NAME_1=ZZZ_node_1 -e NODE_NAME_2=ZZZ_node_2
+```
+
+In a separate terminal, ping the node 2 from node 1.
+
+```
+podman exec -it ZZZ_node_1 ping 10.0.1.2
+```
+
+### test4: multiple compose files and container commands
+
+Docker-compose has the ability to specify multiple compose files that
+are merged together into a single runtime configuration. This test
+has conlink configuration spread across multiple compose files and
+a separate network config file. The network configuration appears at the
+top-level of the compose files and also within multiple compose
+service definitions.
+
+Run docker-compose using two compose files. The first defines the
+conlink/network container and a basic network configuration that
+includes a router and switch (`s0`). The second defines a single
+container (`node1`) and switch (`s1`) that is connected to the router
+defined in the first compose file.
+
+```
+echo "COMPOSE_FILE=examples/test4-multiple/base-compose.yaml:examples/test4-multiple/node1-compose.yaml" > .env
+docker-compose up --build --force-recreate
+```
+
+Ping the router host from `node`:
+
+```
+docker-compose exec node1 ping 10.0.0.100
+```
+
+Restart the compose instance and add another compose file that defines
+two node2 replicas and a switch (`s2`) that is connected to the
+router.
+
+```
+echo "COMPOSE_FILE=examples/test4-multiple/base-compose.yaml:examples/test4-multiple/node1-compose.yaml:examples/test4-multiple/nodes2-compose.yaml" > .env
+docker-compose up --build --force-recreate
+```
+
+From both `node2` replicas, ping `node1` across the switches and `r0` router:
+
+```
+docker-compose exec --index 1 node2 ping 10.1.0.1
+docker-compose exec --index 2 node2 ping 10.1.0.1
+```
+
+Restart the compose instance and add another compose file that starts
+conlink using an addition network file `web-network.yaml`. The network
+file starts up a simple web server on the router.
+
+```
+echo "COMPOSE_FILE=examples/test4-multiple/base-compose.yaml:examples/test4-multiple/node1-compose.yaml:examples/test4-multiple/nodes2-compose.yaml:examples/test4-multiple/all-compose.yaml" > .env
+docker-compose up --build --force-recreate
+```
+
+From the second `node2`, perform a download from the web server running on the
+router host:
+
+```
+docker-compose exec --index 2 node2 wget -O- 10.0.0.100
+```
+
+Remove the `.env` file as a final cleanup step:
+
+```
+rm .env
+```
+
+
+### test5: conlink on two hosts with overlay connectivity via geneve
+
+Launch a compose instance on host 1 and point it at host 2:
+
+```
+echo "REMOTE=ADDRESS_OF_HOST_2" > .env
+echo "NODE_IP=192.168.100.1" > .env \
+docker-compose --env-file .env -f examples/test5-geneve-compose.yaml up
+```
+
+Launch another compose instance on host 2 and point it at host 1:
+On host 2 run conlink like this:
+
+```
+echo "REMOTE=ADDRESS_OF_HOST_1" > .env
+echo "NODE_IP=192.168.100.2" >> .env \
+docker-compose --env-file .env -f examples/test5-geneve-compose.yaml up
+```
+
+On host 1, start a tcpdump on the main interface capturing Geneve
+(encapsulated) traffic:
+
+```
+sudo tcpdump -nli eth0 port 6081
+```
+
+On host 2, start a ping within the "node1" network namespace created
+by conlink:
+
+```
+docker-compose -f examples/test5-geneve-compose.yaml exec node ping 192.168.100.1
+```
+
+On host 1 you should see bi-directional encapsulated ping traffic on the host.
+
+
+### test6: conlink on two hosts deployed with CloudFormation
+
+This test uses AWS CloudFormation to deploy two AWS EC2 instances that
+automatically install, configure, and start conlink (and dependencies)
+using the `test5-geneve-compose.yaml` compose file.
+
+Authenticate with AWS and set the `MY_KEY`, `MY_VPC`, and `MY_SUBNET`
+variables to refer to a preexisting key pair name, VPC ID, and Subnet
+ID respectively. Then use the AWS CLI to deploy the stack:
+
+```
+export MY_KEY=... MY_VPC=... MY_SUBNET=...
+aws --region us-west-2 cloudformation deploy --stack-name ${USER}-conlink-test6 --template-file examples/test6-cfn.yaml --parameter-overrides KeyPairName=${MY_KEY} VpcId=${MY_VPC} SubnetId=${MY_SUBNET}
+```
+
+The stack will take about 8 minutes to finish deploying. You can
+reduce the time to under a minute if you create your own AMI with the
+pre-signal steps in `BaseUserData` baked in and modify the template to
+use that instead.
+
+Once the stack is finish deploying, show the outputs of the stack
+(including instance IP addresses) like this:
+
+```
+aws --region us-west-2 cloudformation describe-stacks --stack-name ${USER}-conlink-test6 | jq '.Stacks[0].Outputs'
+```
+
+Use ssh to connect to instance 1 and 2 (as the "ubuntu" user), then
+sudo to root and cd into `/root/conlink`. You can now run the tcpdump
+and ping test described for test5.
+
+
+### test7: MAC, MTU, and NetEm settings
+
+This example demonstrates using interface MAC, MTU, and NetEm (tc
+qdisc) settings.
+
+Start the test7 compose configuration:
+
+```
+docker-compose -f examples/test7-compose.yaml up --build --force-recreate
+```
+
+Show the links in both node containers to see that the MAC addresses
+are `00:0a:0b:0c:0d:0*` and the MTUs are set to `4111`.
+
+```
+docker-compose -f examples/test7-compose.yaml exec --index 1 ip link
+docker-compose -f examples/test7-compose.yaml exec --index 2 ip link
+```
+
+Ping the second node from the first to show the the NetEm setting is
+adding 40ms delay in both directions (80ms roundtrip).
+
+```
+docker-compose -f examples/test7-compose.yaml exec --index 1 node ping 10.0.1.2
+```
+
+### test8: Connections to macvlan/vlan host interfaces
+
+This example has two nodes with web servers bound to local addresses.
+The first node is connected to a macvlan sub-interfaces of a host
+physical interface. The second node is connected to a VLAN
+sub-interface of the same host (using VLAN ID/tag 5). Static NAT
+(SNAT+DNAT) is setup inside each container to map the external
+address/interface to the internal address/interface (dummy) where the
+web server is running.
+
+Create an environment file with the name of the parent host interface
+and the external IP addresses to assign to each container:
+
+```
+cat << EOF > .env
+HOST_INTERFACE=enp6s0
+NODE1_HOST_ADDRESS=192.168.0.32/24
+NODE2_HOST_ADDRESS=192.168.0.33/24
+EOF
+```
+
+Start the test8 compose configuration using the environment file:
+
+```
+docker-compose --env-file .env -f examples/test8-compose.yaml up --build --force-recreate
+```
+
+Connect to the macvlan node (NODE1_HOST_ADDRESS) from an external host
+on your network (traffic to macvlan interfaces on the same host is
+prevented):
+
+```
+ping -c1 192.168.0.32
+curl 192.168.0.32
+```
+
+Note: to connect to the vlan node (NODE2_HOST_ADDRESS) you will need
+to configure your physical switch/router with routing/connectivity to
+VLAN 5 on the same physical link to your host.
+
+## GraphViz network configuration rendering
+
+You can use d3 and GraphViz to create a visual graph rendering of
+a network configuration. First start a simple web server in the
+examples directory:
+
+```
+cd examples
+python3 -m http.server 8080
+```
+
+Use the `net2dot` script to transform a network
+configuration into a GraphViz data file (dot language). The `net2dot`
+script supports `--compose-file` and `--network-file` command line
+options. To render the network configuration for example test1, run
+the following in another window:
+
+```
+./net2dot --compose-file examples/test1-compose.yaml > examples/data.dot
+```
+
+Then load `http://localhost:8080` in your browser to see the rendered
+image.
+
+The file `examples/net2dot.yaml` contains a configuration that
+combines many different configuration elements (veth links, dummy
+interfaces, vlan type links, tunnels, etc).
+
+```
+./net2dot --network-file examples/net2dot.yaml > examples/data.dot
+```
+
+Then load `http://localhost:8080` in your browser.
+
+
+## Copyright & License
+
+This software is copyright Viasat and subject to the terms of the
+Mozilla Public License version 2.0 (MPL.20). A copy of the license is
+located in the LICENSE file at the top of the repository or available
+at https://mozilla.org/MPL/2.0/.
+

package/TODO

@@ -0,0 +1,34 @@
+- MVP for ViaBox:
+    - [x] compose/x-network file loading
+    - [x] multiple config sources and merging
+    - [x] link route config
+    - [x] filtering on project and workdir
+    - [x] interface and MAC iteration
+    - [x] variable templating
+    - [x] *vlan type interfaces
+
+- Near term:
+    - [x] dummy interfaces
+    - [x] arbitrary container commands
+    - [x] schema validation
+    - [x] code comments/documentation
+    - [x] tunnel interfaces
+    - [x] tc/qdisc settings
+    - [x] fix/test all examples (6 and 9 remaining)
+    - [x] add net2dot
+    - [ ] add outer-netem (and match all link-add params to link keys)
+
+- Further term:
+    - [ ] CNI networking support
+        - conlink runs in container listening for events on a UDS
+          (intead of docker events)
+        - an outer conlink command is the CNI client that formats
+          events to send over the UDS to the inner conlink
+    - [ ] multiple routes
+    - [ ] ovs flow config
+    - [ ] Multiple bridge-modes
+        - bridge-mode as part of the domain definition so that the
+          same conlink instances can support multiple bridge modes
+          simultaneously (with a default for links that don't
+          specify).
+

package/conlink

@@ -0,0 +1,11 @@
+#!/usr/bin/env bash
+
+TOP_DIR=$(dirname $(readlink -f "${0}"))
+SCRIPT_NAME=$(basename "${0}")
+NBB=${TOP_DIR}/node_modules/.bin/nbb
+
+die() { echo >&2 "${*}"; exit 1; }
+
+[ -e "${NBB}" ] || die "Missing ${NBB}. Maybe run 'npm install' in ${TOP_DIR}?"
+
+exec ${NBB} -cp "${TOP_DIR}/src" -m conlink.core/main "${@}"

package/conlink-start.sh

@@ -0,0 +1,172 @@
+#!/usr/bin/env bash
+
+set -e
+
+usage () {
+    echo "${0} [CONLINK_OPTIONS] CONFIG_OPTIONS [-- CMD_OPTIONS]"
+    echo ""
+    echo "Where CONLINK_OPTIONS are:"
+    echo "   --verbose              - Enable verbose output"
+    echo "   --dry-run              - Show what would be done"
+    echo "   --mode MODE            - Conlink launch mode: podman, docker"
+    echo "                            (default: podman)"
+    echo "   --image IMAGE          - Conlink image to use"
+    echo "                            (default: conlink)"
+    echo "   --host-mode HOST_MODE  - External container manager mode:"
+    echo "                            podman, docker, none"
+    echo "                            (default: none)"
+    echo ""
+    echo "Where CONFIG_OPTIONS are (at least one must be specified):"
+    echo "   --network-file NET_CFG  - Conlink network config file"
+    echo "   --compose-file COM_CFG  - Compose file containing conlink service"
+    echo "                             with an optional an x-network key"
+}
+
+VERBOSE=${VERBOSE:-}
+DRY_RUN=${DRY_RUN:-}
+MODE=${MODE:-podman}
+IMAGE="${IMAGE:-conlink}"
+HOST_MODE=${HOST_MODE:-}
+HOST_NETWORK=${HOST_NETWORK}
+CMD="${CMD:-/app/build/conlink.js}"
+NETWORK_FILE=${NETWORK_FILE:-}
+COMPOSE_FILE=${COMPOSE_FILE:-}
+COMPOSE_PROJECT=${COMPOSE_PROJECT:-}
+
+die() { echo >&2 "${*}"; exit 1; }
+vecho() { [ "${VERBOSE}" ] && echo "${@}" || true; }
+
+psvc=
+cleanup() {
+    trap - EXIT INT TERM
+    echo "Cleaning up"
+    if [ "${psvc}" ]; then
+      kill ${psvc}
+      [ -e "${HOST_SOCK_PATH}" ] && rm -f "${HOST_SOCK_PATH}"
+    fi
+}
+
+# Parse arguments
+CMD_OPTS=
+while [ "${*}" ]; do
+  param=$1; OPTARG=$2
+  case ${param} in
+  -v|--verbose) VERBOSE=1 CMD_OPTS="${CMD_OPTS} -v" ;;
+  #-vv) VERBOSE=1 CMD_OPTS="${CMD_OPTS} -v -v" ;;
+  --dry-run) DRY_RUN=1 ;;
+  --mode) MODE="${OPTARG}"; shift ;;
+  --image) IMAGE="${OPTARG}"; shift ;;
+  --host-mode) HOST_MODE="${OPTARG}"; shift ;;
+  --network-file) NETWORK_FILE="${OPTARG}"; shift ;;
+  --compose-file) COMPOSE_FILE="${OPTARG}"; shift ;;
+  --compose-project) CMD_OPTS="${CMD_OPTS} --compose-project ${OPTARG}"; shift ;;
+  -h|--help) usage ;;
+  --) shift; break ;;
+  *) CMD_OPTS="${CMD_OPTS} $1" ;;
+  esac
+  shift
+done
+CCMD="${MODE}"
+[ "${DRY_RUN}" ] && CCMD="echo ${CCMD}"
+# Remaining args are for podman/docker
+
+### Sanity checks
+
+# TODO: check for openvswitch and geneve
+
+case "${MODE}" in
+  podman|docker) ;;
+  *) die "Unknown mode '${MODE}'" ;;
+esac
+[ "${NETWORK_FILE}" -o "${COMPOSE_FILE}" ] || \
+  die "One or both required: --network-file or --compose-file"
+
+### Construct command line arguments
+vecho "Settings:"
+RUN_OPTS="${RUN_OPTS} --security-opt apparmor=unconfined"
+
+vecho "  - mount network/compose config files"
+if [ "${NETWORK_FILE}" ]; then
+  network_path=/root/$(basename ${NETWORK_FILE})
+  RUN_OPTS="${RUN_OPTS} -v $(readlink -f ${NETWORK_FILE}):${network_path}:ro"
+  CMD_OPTS="${CMD_OPTS} --network-file ${network_path}"
+fi
+if [ "${COMPOSE_FILE}" ]; then
+  compose_path=/root/$(basename ${COMPOSE_FILE})
+  RUN_OPTS="${RUN_OPTS} -v $(readlink -f ${COMPOSE_FILE}):${compose_path}:ro"
+  CMD_OPTS="${CMD_OPTS} --compose-file ${compose_path}"
+fi
+
+# podman specific settings and shared container storage
+case "${MODE}" in
+  podman)
+    vecho "  - support running systemd in containers"
+    RUN_OPTS="${RUN_OPTS} --systemd=always"
+    vecho "  - port forwarding with slirp4netns (for rootless mode)"
+    RUN_OPTS="${RUN_OPTS} --network=slirp4netns:port_handler=slirp4netns"
+    if [ "$(id -u)" = 0 ]; then
+        host_containers=/var/lib/containers
+    else
+        host_containers=$HOME/.local/share/containers
+    fi
+    vecho "  - mount shared storage from ${host_containers}"
+    RUN_OPTS="${RUN_OPTS} -v ${host_containers}:/var/lib/host-containers:ro"
+    ;;
+esac
+
+# permissions/capabilities
+if [ "$(id -u)" = 0 ]; then
+  vecho "  - adding base capabilities"
+  RUN_OPTS="${RUN_OPTS} --cap-add SYS_ADMIN --cap-add NET_ADMIN"
+  RUN_OPTS="${RUN_OPTS} --cap-add SYS_NICE --cap-add NET_BROADCAST"
+  RUN_OPTS="${RUN_OPTS} --cap-add IPC_LOCK"
+else
+  vecho "  - adding --priviledged (for rootless)"
+  RUN_OPTS="${RUN_OPTS} --privileged"
+fi
+
+# Warning: --pid host (without cgroup v2) can leak conmon processes to
+# the outer host if the internal cleanup doesn't complete fully.
+case "${HOST_MODE}" in
+  podman)
+    vecho "  - adding connectivity to outer podman"
+    RUN_OPTS="${RUN_OPTS} --pid host"
+    HOST_SOCK_PATH=$(mktemp -u $(pwd)/podman.sock.XXXXXXXXXX)
+    RUN_OPTS="${RUN_OPTS} -v ${HOST_SOCK_PATH}:/var/run/podman/podman.sock"
+    ;;
+  docker)
+    vecho "  - adding connectivity to outer docker"
+    RUN_OPTS="${RUN_OPTS} --pid host"
+    RUN_OPTS="${RUN_OPTS} -v /var/lib/docker:/var/lib/docker"
+    RUN_OPTS="${RUN_OPTS} -v /var/run/docker.sock:/var/run/docker.sock"
+    ;;
+  none|"")
+    ;;
+  *) die "Unknown host mode '${HOST_MODE}'" ;;
+esac
+
+
+### Start it up
+
+trap cleanup EXIT INT TERM
+
+### Start podman API service for external podman connectivity
+
+if [ "${HOST_MODE}" = "podman" ]; then
+  vecho "Starting outer podman API service"
+  rm -f "${HOST_SOCK_PATH}"
+  ${DRY_RUN:+echo} podman system service --time=0 "unix://${HOST_SOCK_PATH}" &
+  psvc=$!   # for cleanup
+  for i in $(seq 5); do
+      [ -e "${HOST_SOCK_PATH}" ] && break
+      echo "Waiting (try $i/5) for podman service to start"
+      sleep 1
+  done
+  [ -e "${HOST_SOCK_PATH}" ] || die "podman service did not start in 5 seconds"
+fi
+
+### Run conlink/docker
+vecho "Starting conlink"
+echo ${MODE} run ${RUN_OPTS} "${@}" ${IMAGE} ${CMD} ${CMD_OPTS}
+[ ${DRY_RUN} ] || ${MODE} run ${RUN_OPTS} "${@}" ${IMAGE} ${CMD} ${CMD_OPTS}
+