Official Docker Image

askingthisonething

As often requested here, we need an official docker image.
Just imagine deployment would be easy as:

fogproject:
  image: fogproject/fogproject:stable
  ports:
    - 0.0.0.0:212:212/udp
    - 0.0.0.0:9:9/udp
   [...]
  volumes:
    - fogproject-images:/images
    - fogproject-database:/var/lib/mysql
    - fogproject-backup:/var/lib/mysql/fogDBbackups
  environment:
    - ADMIN_USER=myadmin
    - ADMIN_PASS=foobar

The world would be a happier place

There are three inofficial (non-functioning) images on hub.docker.com that attempts to provide FOG as an Image with >100k pulls. This shows me that a) there is a demand for a docker image and b) everybody of 100k people probably tried every one of the three images before giving up.

I tried all solutions I can find online, to no avail. Every unofficial solution has major bugs.

An official docker image would accelerate the development of FOG, as it is far easier to deploy and iterate.

Dear devs, are there any plans for an official docker image?

Sebastian Roth

@askingthisonething As soon as at least one person (better two) opt in to maintain the docker image we are ready to go.

dimoura

Friends… I also tested several images on dockhub but I wasn’t successful… I look forward to it and hope that they develop an official image for docker… It would make deployment a lot easier…

Sebastian Roth

@dimoura At the risk of repeating myself, someone needs to make a commitment to maintain the docker image. This is not going to happen if everyone keeps asking for others to do it.

austinalex23

Popping in to say that I recently created a request on the linuxserver.io forum for the creation of a Fog container. I updated that request with a link to this post in an effort to encourage a followup.

austinalex23

I did just find an image that works. (It works meaning I’m able to access the FOG interface. It’s outdated but it’s there).

I used the following docker compose:

version: '3.4'

services:
  fogserver:
    image: mudislander/fogproject:latest
    container_name: fogproject
    environment:
      IP: 192.168.1.225
      WEBSERVER_HTTP_PORT: 80
      APACHE_ROOT_REDIRECTION: "<OPTIONAL_URL>"
    ports:
      - 80:80/tcp
      - 69:69/tcp
      - 69:69/udp
      - 21:21/tcp
#      - 443:443/tcp
      - 9000:9000/tcp
    restart: always
    volumes:
      - <PATH_TO_LOCAL_IMAGES_FOLDER>:/images
      - <PATH_TO_LOCAL_MYSQL_DATA_FOLDER>:/var/lib/mysql

george1421

@austinalex23 said in Official Docker Image:

ports:
  - 80:80/tcp
  - 69:69/tcp
  - 69:69/udp
  - 21:21/tcp
  - 443:443/tcp
  - 9000:9000/tcp

You will need additional ports in the mix for NFS. Out of the box FOG uses NFS v3 which is a port nightmare. If you configure the fog server to use NFS v4 then you can get away with ports 111 and 2049 for NFS parts of imaging.

This next bit is going to show my ignorance of docker, but how does a docker image help you with FOG? You are basically port forwarding the physical ports to the docker internal ports, in that you can’t use those ports for other apps that might run on that docker server. What value does this indirection give you over just a physical or virtual server? To me it looks just like extra overhead.

Where I can see value in docker if you were running multiple CMS systems where you put a reverse proxy in front of the docker containers so you can switch which container gets the port 80 traffic based on the fqdn host name. I can see other uses, but related to FOG Imaging.

austinalex23

@askingthisonething For me it’s mostly a convenience thing. I’m already running a Debian VM with half a dozen Docker container services, so being able to spin up FOG in the same place where I can manage it with the same interface as everything else would be preferable. The ports aren’t an issue because you have the ability to map the ports the container uses internally to whatever ports you want on the host.

In a world where an official Docker image existed and was maintained, it would also be a lot faster and easier for people to create a FOG instance in their environment, in that all they would need to do is run a Docker run command or deploy a Docker compose file to get it up as opposed to setting up a new VM and then going through the installation script. Updating would also be as simple as pulling the latest image from Dockerhub rather than downloading the newest install script and running it again (which can be automated so you don’t even notice).

TopHatProductions115

I’m a Docker/Compose newb myself, but I’m willing to help with testing. Maybe even container image creation if necessary. I’ve never made a container image before. Perhaps this would be a good time for me to pick up a new skill?

Official Docker Image

196

12.0k

17.3k

155.2k