setup.sh scripts are only useful for Triton Cloud

[Smithx10]

I used cloudapi.example.com and dockerapi.example.com for my installation, is there a better way to do this check?

# make sure Docker client is pointed to the same place as the Triton client
local docker_user=$(docker info 2>&1 | awk -F": " '/SDCAccount:/{print $2}')
local docker_dc=$(echo $DOCKER_HOST | awk -F"/" '{print $3}' | awk -F'.' '{print $1}')
TRITON_USER=$(triton profile get | awk -F": " '/account:/{print $2}')
TRITON_DC=$(triton profile get | awk -F"/" '/url:/{print $3}' | awk -F'.' '{print $1}')
TRITON_ACCOUNT=$(triton account get | awk -F": " '/id:/{print $2}')
if [ ! "$docker_user" = "$TRITON_USER" ] || [ ! "$docker_dc" = "$TRITON_DC" ]; then
    echo
    tput rev  # reverse
    tput bold # bold
    echo 'Error! The Triton CLI configuration does not match the Docker CLI configuration.'
    tput sgr0 # clear

Hard Coded the domain name:
# setup environment file
if [ ! -f "_env" ]; then
echo '# Consul bootstrap via Triton CNS' >> _env
echo CONSUL=consul.svc.${TRITON_ACCOUNT}.${TRITON_DC}.cns.joyent.com >> _env
echo >> _env

[tgross]

Just so that I understand correctly -- you're trying to deploy to a private cloud Triton installation?

If so, at the end of the setup the only thing that the setup.sh does is creates the _env file with the env var CONSUL=consul.svc.${TRITON_ACCOUNT}.${TRITON_DC}.cns.joyent.com. So you'd replace ${TRITON_DC}.cns.joyent.com with your own CNS domain. That being said, it seems like it'd be nice if we could have the setup.sh script accommodate private Triton too.

(Also, I've edited the title for accuracy: JPC is what Joyent used to call what is now known as Triton Cloud.)

[Smithx10]

Morning tgross,

Currently I have Triton Cloud setup for my own dev / testing etc. I was working on getting consul and a few other services running on autopilot and figured I would mention any pain points I come across. I think the pattern is way more powerful than something like a DC/OS framework for obvious reasons, and would like to make more of them, but I am still getting up to speed on how it all works.

Perhaps tritoncli needs something like "triton validate profile"

[gbmeuk]

I hit the same issue when running against a private cloud installation but it was straight forward to work out what the script was doing and make the alteration.

Agreed, it would be nice to make it validate differently. Isn't the case, simply to run triton info and docker info and ensure we're getting expected results; then only perform this check if the ${TRITON_DC} matches a Triton Cloud address?

[tgross]

Just FYI on this long-open issue, in autopilotpattern/nginx#42 (once it's merged) we'll have introduced a layout for these projects that lets us have different deployment targets for examples (ex. "compose" for Docker Compose locally, "triton" for Triton, opportunity for 3rd-party targets like k8s, etc.). So once we're happy with that and have worked any kinks out I'll circle back here and introduce it into this repo.

[Smithx10]

Is there any place where I can test/view this new layout? I am also running manta internally and would like to commit / help etc.

[tgross]

@Smithx10 the layout for Nginx is now in master, and we've got a nice version of the layout in https://github.com/autopilotpattern/redis as well.

[jwreagor]

I'm going to close this considering the rework done previously. Feel free to re-open or comment if applicable.