I just wanted to drop a note of appreciation concerning the Container setup available for Fossil. With just a change for Repolist and HTTPS I was able to use the default Dockerfile to deploy Fossil into an Azure App Service Container and now have a fully working Fossil site in Azure. The current version of the Dockerfile made this a breeze, considering I have no easy way to compile Fossil on Linux. The integrated build in the imaging process worked like a charm.

Thanks!

I just wanted to drop a note of appreciation concerning the Container setup available for Fossil.

As the author of same, I thank you for the kindness. It is always motivating to know that people are using and finding value in your work.

I've known that for some time by proxy, since the pull numbers on the tangentsoft/fossil image on Docker Hub keep going up independently, between upgrades to tangentoft.com, but this may be the first time any of these other users have identified themselves in person. Hello!

Those pull numbers are definitely cooked. I've seen it go up by 2 for a single pull, for one thing. I'm guessing Docker Hub counts a client's prospective HTTP HEAD call to check for a change relative to a local cached version as a "pull" even when it's immediately followed by a GET to pull the new version.

What's worse is that if you have multiple Fossil containers on a single box, as I do on tangentsoft.com, Podman is smart enough to pull it only once and reuse the image, but the download counts on Docker Hub go up by the container count for that box on upgrade.

And then even worse, these two factors appear to multiply. I have a dozen containers on that box, so an upgrade to tangentsoft.com causes a +24 to the Docker Hub pull count on each upgrade!

I'd worry that I was responsible for all the downloads if the pull numbers weren't continuing to go up between my site upgrades. Someone else is using this container; likely several someones, because I cannot account for the current 7830 pulls all by myself.

With just a change for Repolist and HTTPS

If you mean that you had to add the --repolist and --https flags, then you didn't need to rebuild the container at all. You merely need to override the default CMD list, seen at the end of the Dockerfile.

Let us say that you wish to drop --create since you will always have a valid repo attached, but you want to keep the "bundled" JS mode enabled, and you do still need to tell the Fossil server about the admin user to keep it from using "root" or whatever Azure gives you as a process owner for a Linux container. I don't know how Azure handles CMD overrides, but in Docker-speak it would be:

  $ docker run tangentsoft/fossil \
    --jsmode bundled \
    --user admin \
    --repolist \
    --https

Any arguments you pass after the image name override CMD in the Dockerfile. Azure must have a way to do this, too.

I care, of course, because if you use my image instead of building your own, my fake Internet points increase faster. :)

If I was running in the Kubernetes service on Azure, or in Azure Container Instances, I'm sure I could override as you indicate. However, I'm running just a single container in the Azure App Service which is very much "container-lite" land. I'm loading the image into Azure Container Registry as well so that the auto-updates on image update function. I also have some restrictions from work, so... I'm pretty much stuck with updating and building my own images at this time.

That said, the only change necessary to run the container in Azure App Services is the use of the --https flag, since Azure App Service is terminating the HTTPS for the container. Mounts are also handled very differently in Azure App Service, but behind the scenes operate as expected. Azure App Service actually lets you use a predefined location for persistent storage for the life of the app service, but only the container can access it, so I'm using Azure Files for the repositories instead.

I'm very new to containers, and the container implementation in Azure App Services is not as well documented as say, Kubernetes. I'm working my way through figuring it all out though. Fossil is my standard package for figuring out interesting things (which is how I ended up writing a large part of the Windows Server Documentation for Fossil).

Thanks again for all your work on the Dockerfile. I looked at several other Dockerfiles for Fossil, but yours is actually probably the best for the scenario I am in.

Following a quick bit of web searching, I believe you can change CMD with what Azure calls the "Startup Command".

Yes, looks like that is the place to put the changes. I'll probably update the setup later today. Right now I'm trying to figure out the proper TZ environment to set... I'm off by one hour. Too used to Windows.

Personally, I let my cloud instances go to UTC. Only my on-prem servers have a local TZ value set.

Fair point! I've changed the stock Dockerfile, regenerated my container image, and tested the change on my site. You should now be able to use tangentsoft/fossil:latest to host your repos as-is.

BEWARE: If there's anyone out there using my fslsrv wrapper script or have anything similar that uses the upstream Dockerfile with overrides of CMD and/or ENTRYPOINT, they'll have to track this change.

I appreciate the change very much.

For now I have to wait as I have not received any feedback from the Security team at work about how they want to handle containers (personally I think they have no clue what I'm even asking about). I will have to continue my own build, as since I'm in total control of that I can verify everything while waiting on the Security team to figure things out (might take years, don't ask how long it took to get approval to use Azure... But I'm years behind where I wanted to be).

Thanks again for all the work you do on Fossil!