Build tend to fail due to DOCKER_TLS_VERIFY=1 not respected by habitus

[mumoshu]

Hi, thanks a lot for sharing a great tool!

TL;DR; I guess habitus should imply -use-tls whenever DOCKER_TLS_VERIFY=1 is set.

DOCKER_TLS_VERIFY=1 seems like being widely-used to tell docker client to talk to the daemon with TLS.

However, habitus as of today doesn't seem to respect the envvar to enable TLS, according to what I see in following reproduction steps:

1. My minikube docker-env does export DOCKER_TLS_VERIFY=1

$ minikube docker-env
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_CERT_PATH="/Users/kuoka-yusuke/.minikube/certs"
export DOCKER_API_VERSION="1.23"
# Run this command to configure your shell:
# eval $(minikube docker-env)

2. I do source it to my shell session so that habitus could pick it up to enable TLS without explicit a -use-tls flag

$ eval $(minikube docker-env)

3. When I run habitus against the default build.yaml included in this habitus repo, unfortunately it fails:

$ habitus
2018/03/07 15:57:45 ▶ Using '/Users/kuoka-yusuke/Repositories/habitus/build.yml' as build file
2018/03/07 15:57:45 ▶ Collecting artifact information
2018/03/07 15:57:45 ▶ Building 2 steps
2018/03/07 15:57:45 ▶ Step 1 - tester, image-name = 'tester'
2018/03/07 15:57:45 ▶ Step 2 - crosscompile, image-name = 'crosscompile'
2018/03/07 15:57:45 ▶ Step 1 - Build for tester
2018/03/07 15:57:45 ▶ Step 1 - Building tester from context '/Users/kuoka-yusuke/Repositories/habitus'
2018/03/07 15:57:45 ▶ Step 1 - Parsing and converting 'Dockerfile.tester'
2018/03/07 15:57:45 ▶ Step 1 - Writing the new Dockerfile into '/Users/kuoka-yusuke/Repositories/habitus/Dockerfile.tester.generated'
2018/03/07 15:57:45 ▶ Step 1 - Building the tester image from /Users/kuoka-yusuke/Repositories/habitus/Dockerfile.tester.generated
2018/03/07 15:57:45 ▶ Build for step tester failed due to Post http://192.168.99.100:2376/build?cpushares=1024&dockerfile=Dockerfile.tester.generated&rm=1&t=tester: malformed HTTP response "\x15\x03\x01\x00\x02\x02\x16"

Note that the malformed HTTP response "\x15\x03\x01\x00\x02\x02\x16" is seen when your docker client is trying to talk to a TLS-enabled daemon without TLS.

4. Explicitly setting -use-tls does fix the error:

$ habitus -use-tls
2018/03/07 15:57:49 ▶ Using '/Users/kuoka-yusuke/Repositories/habitus/build.yml' as build file
2018/03/07 15:57:49 ▶ Collecting artifact information
2018/03/07 15:57:49 ▶ Building 2 steps
2018/03/07 15:57:49 ▶ Step 1 - tester, image-name = 'tester'
2018/03/07 15:57:49 ▶ Step 2 - crosscompile, image-name = 'crosscompile'
2018/03/07 15:57:49 ▶ Step 1 - Build for tester
2018/03/07 15:57:49 ▶ Step 1 - Building tester from context '/Users/kuoka-yusuke/Repositories/habitus'
2018/03/07 15:57:49 ▶ Step 1 - Parsing and converting 'Dockerfile.tester'
2018/03/07 15:57:49 ▶ Step 1 - Writing the new Dockerfile into '/Users/kuoka-yusuke/Repositories/habitus/Dockerfile.tester.generated'
2018/03/07 15:57:49 ▶ Step 1 - Building the tester image from /Users/kuoka-yusuke/Repositories/habitus/Dockerfile.tester.generated
Step 1/7 : FROM golang:1.8
 ---> 0d283eb41a92
Step 2/7 : MAINTAINER Daniël van Gils
 ---> Using cache
 ---> 528a6a31df50
Step 3/7 : RUN go get github.com/onsi/ginkgo/ginkgo
 ---> Running in ef58e5651ff7

[khash]

Thank you for your detailed comments and the pull request. I think your point is valid and the PR is now merged.