I previously posted about an issue where the nginx container for the Collabora application logs a GET to /robots.txt every 10 seconds. I tried modifying the files in the container, but they were reset on restart. I also tried to run the container with --log-driver=none, but was unsuccessful. Despite being a software dev, I’m new to the homelab world and trunas.

I solved it by changing the docker image and then committing those changes. The change I made was to set access_log off; in the nginx config. I did it at the server root because I don’t really care about those logs for this app, but it could be done on the location level.

Here’s how I did it: Here’s the reference SO post that I used: https://stackoverflow.com/a/74515438

What I did was I shelled into the image:

  • sudo docker exec -it ix-collabora-nginx-1 bash
  • apt update && apt install vim
  • vi /etc/nginx/nginx.conf and add the access_log off;
    • if you’re not familiar with vim, arrow key to the line you want then press ‘a’ to enter “append mode”. Make your change, then esc, :wq!. You need the ! because the file is read only
  • apt remove vim
  • exit
  • sudo docker commit <image id>
  • sudo docker restart ix-collabora-nginx-1
  • ikidd@lemmy.worldEnglish
    2·
    7 hours ago

    If you’d done a docker commit on your earlier changes, they’d have stuck as well.

    The proper way to do this is to fork their image project and alter the nginx files that get incorporated in the build. Then you can run the stack with a build command instead of an image reference, and git pull your fork whenever there’s upstream merges. Or Action the fork to build an image for you every time it gets merged that you reference in your docker compose instead.

  • hempster@lemm.eeEnglish
    2·
    1 day ago

    TIL sudo docker commit <image id> So, what happens if you get updates in tags you follow? Do you have to commit again? Isn’t it a temporary measure? I still think, you should rebase a new image on top of whatever tagged version you trail.

    • RagingHungryPanda@lemm.eeOPEnglish
      1·
      1 day ago

      I think this would be a better approach. Mine is likely temporary. I have a better approach like this one in my backlog to figure out

  • catloaf@lemm.eeEnglish
    6·
    2 days ago

    Either this means you won’t get future updates, or future updates will still overwrite your change. The proper way to do this would be to mount your own config over the one in the container, though this may have negative effects if the container config changes in the future. You might be able to mount /dev/null over the log file if you don’t care about the logs at all.

    I don’t believe there’s any way to specify modifications to someone else’s containers without making your own image, unfortunately.

    • RagingHungryPanda@lemm.eeOPEnglish
      2·
      2 days ago

      So an issue i had was that I’d try to mount folders to this image but they wouldn’t show up, but when I tried mounting it to a different image, it did. I’m not sure what I did wrong here, but I worked at it for a while and I’m still new to TruNas. But at least with this image, I don’t mind too much about updates and it’s an easy change that I can do again. Thanks for the feedback though, I’ll be keeping this in mind and try to do things in a more “correct” manner 🙂

      • Oisteink@feddit.nlEnglish
        2·
        2 days ago

        This is not a truenas issue - its a docker thing. You’d do better by making your own docker-file and do your customisation the docker way.