New to Discourse. Had a VM from Bitnami almost completely running and then found out about your new Docker recommendation. I’ve now got a new VM running, and the docker installation is running and tested. But I installed it in Azure and the Docker daemon is set up to require TLS as noted here on Docker site: https://docs.docker.com/articles/https/
I think the launcher is failing because it’s not attempting to use Docker with https.
Am I missing something very basic here. Totally new to Docker but following your instructions and I had all the Discourse parts in their respective places. My app.yml was configured. But as I said, cannot run the Launcher script.
std.out I get when Launcher fails:
2014/12/21 00:41:14 Get http:///var/run/docker.sock/v1.12/info: dial unix /var/r
un/docker.sock: no such file or directory
Cannot connect to the docker daemon - verify it is running and you have access
I did a ‘reinstall’ and some restarting. I have a feeling that the way that MS instantiates the VM with Docker included as an ‘extension’ is part of the problem. I show input from docker info and which below.
bdelaney@dfdiscourse:~$ docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): linux/amd64
FATA[0000] Get http:///var/run/docker.sock/v1.16/version: dial unix /var/run/doc
ker.sock: no such file or directory. Are you trying to connect to a TLS-enabled
daemon without TLS?
bdelaney@dfdiscourse:~$ which docker.io
bdelaney@dfdiscourse:~$ which docker
/usr/local/bin/docker
The command docker info does not work at all. I get the following:
bdelaney@dfdiscourse:~$ docker info
FATA[0000] Get http:///var/run/docker.sock/v1.16/info: dial unix /var/run/docker
.sock: no such file or directory. Are you trying to connect to a TLS-enabled daemon without TLS?
In another local VM (not MS installed on Azure) I’m running docker and both docker info and docker version work. But in that VM Docker is not installed in /usr/local/bin. In the Azure VM I’m trying to install Discourse to, docker.sock does not appear to exist under /var/run. Thus the output above for info and version.
My reinstall and restart did not seem to accomplish anything.
Not a Linux user so this is a little foreign to me. But I followed the ‘prescribed’ way to bring up a docker enabled VM in Azure. I did this with Azure xplat-cli tools running in a local Ubuntu VM
From reading the Launcher script I doubt that I can just use the Docker tools to bring up a container myself without using your bootstrap process. But at this point, I think the problem lies with the special MS install pattern. I believe that this is a possible use case for you in the future though as many developers will operate a Linux VM in the MS Azure cloud. And they are being ‘proscriptive’ about how to create Dockerized Linux VMs.
Happy to provide more details and take steps to reproduce the problem. Will follow any recommendations you make and I’ll keep on troubleshooting via Google as much as possible.
I think the ideas behind Discourse and its implementation are great. I had a taste of it with my blog when I brought up the Bitnami instance, but then decided to follow your latest recommendation regarding Docker. I’m willing to go the extra mile to get it working on Azure and I’ll document it comprehensively if I ever get it running.
Opening a topic at docker forums seems unnecessary. From your response am I to gather that the Launcher will not work with a TLS-enabled daemon. It’s the Launcher that I have to work with right? And the options don’t suggest a way to have the Launcher called in the case of a TLS enabled daemon:
echo "Usage: launcher COMMAND CONFIG [--skip-prereqs]"
42 echo "Commands:"
43 echo " start: Start/initialize a container"
44 echo " stop: Stop a running container"
45 echo " restart: Restart a container"
46 echo " destroy: Stop and remove a container"
47 echo " enter: Use nsenter to enter a container"
48 echo " ssh: Start a bash shell in a running container"
49 echo " logs: Docker logs for container"
50 echo " mailtest: Test the mail settings in a container"
51 echo " bootstrap: Bootstrap a container for the config based on a template"
52 echo " rebuild: Rebuild a container (destroy old, bootstrap, start new)"
53 echo
54 echo "Options:"
55 echo " --skip-prereqs Don't check prerequisites"
56 exit 1
IMHO the use case is compelling enough that the Launcher script can be refactored to use the TLS enabled daemon.
Am I missing something? Are you telling me I can work without going through the Launcher to set up the Discourse container on the host?
sorry, but showing my Linux ignorance. I tried to explain that the way Microsoft enables Docker is through an Azure process called ‘Extensions’ which are used for both Linux and Windows VMs. The creation of my VM was done in this proscriptive manner and as it executed from my workstation, it built in the https client/server. Baking it in this way means that my Docker client works fine over https when I am in the local Linux VM from which I executed the Azure VM Creation. Somehow it defaults to running with --tls with every command.
So, to answer your questions, Yes, each time I run the Docker client, in my local VM, I’m automatically running over https. But it has all been created ‘automagically’ when the Azure ‘create VM’ script is called.
I’m hesitant to start all over again with another VM based on the Bitnami image for Discourse 1.13. That felt like more familiar ground. But I do want to fall into step with where your team is going and that seems to be Docker. Far as I can tell, I’m very close, just don’t understand how to modify the Launcher script to run Docker client in TLS mode.
I went ahead with a completely new instance of the Bitnami VM on Azure. I
don’t think that my point about a valid use case for the Launcher script
exists when you have an https secured Docker daemon hit home here. I’ll try
and take it up with the Microsoft team working on Docker when I have more
time.
For now, I had to move forward on connecting my blog to Discourse so I had
to have a functional instance running.
I don’t really foresee trying this out with an entirely different hosting
service because Azure is the way we roll in my shop.