1). My Dockerfile includes the directive “Expose 3000”, but when I open the service Edit dialog, I see that the following ports are “mappable”: 3000, 443, 80. I understand that 443 is the SSL port, but where did the definitions for 443 and 80 come from (they are not in my Dockerfile, nor any parent files).
2). Aside from that, if I register a public port (say 3000->3000 or 4000->80) and then try to access this port via HTTP on the container’s host, then I still get a 404. The image runs fine on my local virtual machine (boot2docker). How would one debug this sort of thing? (BTW, other services that I have deployed work as expected).
80 and 443 come from your image -> jadsonlourenco/docker-meteor-base -> phusion/passenger-customizable
I’m just on my phone now but will try your dockerfile later tonight. Since you’re getting back a 404 page you’re either hitting some process running. If that process is in the container then the problem isn’t port mapping. So you could stop that container and should get no response now, if you do then some other container or process on the host has that port (that shouldn’t be possible in a host only using Rancher, but I don’t think the scheduler considers ports used outside of docker).
Or maybe there is another process listening on that port
I’ve just tried this and have exec into the container and can’t curl to either port 3000 or 80 so not sure anything is listening on it. Vince is correct though that if you are getting a 404, you must be hitting something. Perhaps Vince will have better luck than me.
Same here… the image in DockerHub has nothing in /home/app. git clone and docker build . says (in step 4):
build: You're not in a Meteor project directory.
To create a new Meteor project:
meteor create <project name>
For example:
meteor create myapp
For more help, see 'meteor --help'.
FYI, the code from Github as it currently is won’t build a working container. The core of Meteor (everything that’s in the /.meteor directory) is gitignored and missing from the repo. So there’s no app to build. Just a sample template with no framework to actually run it in.
Also, @richburdon have you checked out any of the top three Meteor base containers on docker hub?
Thanks Vincent and Jeremy, but the Dockerfile has:
WORKDIR /home/src/demo
RUN meteor build .
Which should rebuild the .meteor state, shouldn’t it? Otherwise it wouldn’t work deploying my image to my local VM? It’s very likely that I’m not getting something about docker (it’s new to me), but my understanding was that “docker build” would fail if this step wasn’t running properly?
Nope. meteor build needs to happen from inside a valid meteor project. That will not work in any directory you run it in (try it).
Either way, you’re not ever supposed to gitignore that directory. It’s what makes a Meteor app a Meteor app. It has all of the info about what version of Meteor you’re using and what packages are installed (among other things). There’s already a generated gitignore file inside /.meteor that hides any of the stuff you don’t want committed.
And if a build worked for you locally, I’m assuming it’s because the ignored directory actually exists on your local machine.
You can give the Meteor build process a try right on your machine. cd into your app and run meteor build .. Then try cloning your repo and doing the same thing. Doing it from a directory without /.meteor results in this:
$ meteor build .
build: You're not in a Meteor project directory.
hi @jeremy, again thanks very much for your time on this.
First, I had assumed that my docker image was independent of my git repository since I’m not invoking “git clone” from the Dockerfile. Therefore, docker build should have all the pieces that are needed to run meteor (i.e., the .meteor) directory – and this is why running the image locally works.
Second, I figured out that my local image runs on my local VM since I’m using docker-compose and my YAML file contains the necessary environment configuration (e.g., MONGO_URL, ROOT_URL); I wasn’t setting these correctly in the Rancher service config – but there were no errors in the container’s log. In fact, I’ve now corrected these envs and the service still isn’t running as expected.
To sanity check, I’ve deployed the same docker hub image on a virgin core OS machine (also running on Digital Ocean) and it runs fine.
So my main problem with Rancher is that it’s obscuring whatever errors are happening during the service set-up (i.e., docker run) and this makes debugging really difficult.
Rancher is quite literally doing docker run just like you would, and shows whatever the container outputs in the Logs screen. What version of Rancher are you running? The only thing I can think of is the websocket connection for logs/stats/shell isn’t working at all, which would have nothing to do with your specific image. If you run a vanilla ubuntu container (click Add Container, give it a name and click Save) can you see the (mostly boring) stat graphs on the container details? Click the Execute Shell action on it, you should be able to use the shell.
This is what the logs screen should look like when you run richburdon/meteor-demo with no environment variables set (and turn off interactive/tty under “Command”):
Yes, I understand rancher is just doing docker run (and docker run is working for me on my local vm and my remote vm at Digital Ocean).
The log you show is what I would expect to see (and what I see locally when I don’t specify docker run env variables), but my logs are empty – with or without the interative/tty options set; I’m a “new user” so can’t upload my screen image, but my log shows the following:
Lastly, I’m not seeing evidence of any of the command in my Dockerfile being executed (e.g., there is no app.tar.gz from the meteor build, nor evidence of directories being created). I don’t see any other signs of errors in the Infrastructure/Container view.
@willchan it seems that many of the problems I’ve been seeing might be related to using CoreOS as the OS for my rancher/server. I will write-up a more detailed list of the errors I’ve encountered, but re-installing the server on Ubuntu resolves the service install problem that prompted this thread.
