Dynamically set env vars passed to `docker run` in unit file based on service's etcd directory

[bmorton]

trafficstars

Is it reasonable for deployster to implement functionality to ease in setting/managing environment variables that are exposed to services by convention?

Update 3/12: In deploying a number of services with this pattern now, it has become apparent that most of the bootstrap that happens on container boot is boilerplate.

Here's what it typically looks like:

#!/bin/bash -l

if [ -z "$CONNECTION_STRING" ]; then
  echo "Setting CONNECTION_STRING via etcd..."
  export CONNECTION_STRING=$(etcdctl get /services/authentication/CONNECTION_STRING)
fi

if [ -z "$MAX_POOL_SIZE" ]; then
  echo "Setting MAX_POOL_SIZE via etcd..."
  export MAX_POOL_SIZE=$(etcdctl get /services/authentication/MAX_POOL_SIZE)
fi

# Execute the commands passed to this script
$@

Given the pattern that is emerging with etcdctl get /services/{name}/{ENV_VARIABLE}, we should be able to do this programmatically when we create the unit template iterating through everything under the /services/{name}/* directory in etcd.

[dcondomitti]

https://github.com/dcondomitti/bridge

[ivanvanderbyl]

@dcondomitti I like that a lot.

[bobbytables]

That's actually pretty cool...

[bmorton]

Yeah, really cool. I started using it in my template for this stuff. Here's what my Dockerfile looks like currently:

FROM golang
MAINTAINER Brian Morton "[email protected]"

ENV APP_NAME myapp
ENV REPO github.com/bmorton/${APP_NAME}

ENV BRIDGE_VERSION v0.0.2-dev
ADD https://github.com/bmorton/bridge/releases/download/${BRIDGE_VERSION}/bridge-linux-amd64 /bin/bridge
RUN chmod +x /bin/bridge

ADD . /go/src/$REPO
RUN cd /go/src/$REPO && go get -v -d
RUN go install $REPO

EXPOSE 3000
ENTRYPOINT exec /bin/bridge -debug -path="/services/${APP_NAME}" -etcd_host=${ETCDCTL_PEERS} /go/bin/scaler
CMD /go/bin/${APP_NAME}

[bmorton]

Given the bridge stuff, does it make sense that deployster would handle this or should it just be responsible for making sure to inject ETCDCTL_PEERS or whatever we want to call it?

@dcondomitti what do you think about changing -etcd_host to either take an array of etcd peers or be definable via some env variable? I like ETCDCTL_PEERS because that's what etcdctl uses, but it doesn't make much sense if you're not using etcdctl. Something generic would make sense from deployster's perspective though.

[bobbytables]

ETCDCTL_PEERS makes sense to me.

[ivanvanderbyl]

@bmorton @dcondomitti switch the CLI to use https://github.com/codegangsta/cli — it supports EnvFlags:

var (
    etcdHostFlag = cli.StringFlag{
        Name:   "etcd-host",
        Value:  "127.0.0.1",
        EnvVar: "ETCDCTL_PEERS",
    }
)

[bobbytables]

There's also envflags https://github.com/ianschenck/envflag/tree/master

[bmorton]

:+1: I use codegangsta/cli for deployctl, if you want to use that as an example, @dcondomitti.