Would like some pointers as to why I can’t seem to access my Grav site set up behind traefik, when my other docker containers have been set up pretty much the same way and are reachable over the internet. Below is my docker-compose yml file:
version: "2.1"
services:
grav:
image: lscr.io/linuxserver/grav
container_name: grav
environment:
- PUID=1000
- PGID=1000
- TZ=Asia/Hong_Kong
volumes:
- /[PATH]/[TO]/[APP]/config:/config
ports:
- 8777:80
restart: always
labels:
# Traefik rules (redacted)
As you can see, I’m trying to use port 8777 on the host and point it to Grav container’s port 80. I’ve verified the routes have been set up correctly in my traefik’s control panel (and all my other containers’ traefik rules have been set up the same way and all work fine).
What am I doing wrong?
I don’t know the image you are using. Does it serve on port 80? They don’t all. Can you shell into the container and curl or wget 127.0.0.1:80?
I don’t know Traefik either, but if that setup works for other containers, it can probably be eliminated for troubleshooting.
Below is the sample .yml the image provided on their site:
version: "2.1"
services:
grav:
image: lscr.io/linuxserver/grav
container_name: grav
environment:
- PUID=1000
- PGID=1000
- TZ=America/New_York
volumes:
- /path/to/appdata/config:/config
ports:
- 80:80
restart: unless-stopped
I assume this should mean the image is serving on port 80?
Not quite sure how to shell into the container, I’d have to look into that.
Is there any other docker image for Grav that you could recommend for trying out?
@Europa2010AD ,
you should be able to shell into the container with
docker exec -it grav bash
as for another docker image, you could try the official grav docker image
Thanks for the tip. I just shelled into the container and tried both wget 127.0.0.1:80 and curl 127.0.0.1:80, with different results:
wget: after it says “connecting to 127.0.0.1:80”, it saved an “index.html” (but I don’t know where).
curl: it simply goes to the next line as if I entered an empty command.
well, that behaviour seems quite normal to me 
wget does fetch and store something when just called like you did (without protocol).
the saved file should just be there where you are inside the container (probably /).
curl, however, will do nothing without explicitly specifying a protocol, e.g.
curl http://127.0.0.1:80
A new one to me and it looks it should serve on port 80. The location of the volumes looks odd though, I don’t see how you would persist the user, backups, or logs folders.
The instructions are very good but generic for docker images. I almost wonder if this is produced by a software factory churning out many of these images for different platforms.
Anyway, I don’t want to disparage something I don’t know very well. There are other images listed on Grav docs now.
Sorry I assumed you were familiar with one of these tools and how to shell in. Only one of wget or curl was needed for checking and we know the answer now anyway 
It’s all good! I’m more of a self-learned enthusiast, so there are many gaps in my knowledge 
I’m giving the official Grav docker-compose a try now, but it seems like I’m unable to pull the official image (error message saying “repository doesn’t not exist”).
[EDIT]: Just figured out it uses Dockerfile to build the image – something I’ve never done before. Got through the documentation on how to do that and am now trying to set it up. Will report back later.
Okay I’ve managed to build the image with Dockerfile via docker-compose successfully, container is up and running but somehow Grav doesn’t seem to be working. Below is the docker-compose .yml I used:
version: "2.1"
services:
grav:
build: ./
container_name: grav
security_opt:
- no-new-privileges:true
volumes:
- /share/[path_to_appdir]:/var/www/html
ports:
- 8765:80
restart: always
DNS still doesn’t resolve. I checked the bind-mount volume as defined in my .yml ([path_to_appdir]), and the folder is empty inside. I shelled into the container, and looked inside /var/www/html and it’s empty as well. There isn’t a /bin/grav folder neither (I think it’s supposed to be one, right?).
What am I doing wrong? After I’ve created the image and spun up the container with docker-compose up -d, is there anything else I need to do?
Let’s leave aside the question of the volumes and get back to your original problem, accessing a container that should be serving Grav at port 8765.
I feel like it would be helpful to know some answers too:
- are you running this on a server?
- which platform is running on the host machine? (I mean the Docker host i.e. the machine running docker, not a web host)
- are you running compose / docker from command line or a graphical client app?
Assuming you have command line access, this is how I tested that the official Grav image worked on my laptop.
In the cloned git hub repository folder:
(you may not need this step because you ran it in compose earlier, won’t hurt to try)
$ docker build -t local/grav-official .
(note trailing dot)
Give the image any name you like, I used hughbris/grav-official, the official example uses just grav. Now:
$ run -d -p 8765:80 local/grav-official:latest
We are not persisting any data for this test so there’s no need to bind a volume.
If you are running this locally, can you access 127.0.0.1:8765 in your browser? On a server, does curl -I 127.0.0.1:8765/admin show a status of ‘200 OK’?
(You can stop your test container when you are finished with docker stop <containerid> where container_id is the long id you saw when you created this container)
If you don’t see any problems in this test (Grav is being served), your problem is upstream with Traefik. I don’t use or know about Traefik. I “tried to try” it once but could not follow the documentation at all.
This official container and the examples are quite different to the setup in this nginx image and my own caddy image. I run both of these images. They are better documented and have a more logical volume setup in my opinion (use bind mounts). They are a different approach anyway.
There are some good outstanding pull requests on the official image which would greatly improve it.