Uploaded image for project: 'Puppet Server'
  1. Puppet Server
  2. SERVER-3077

docker container: Make r10k.yaml persistent



    • Template:
    • Acceptance Criteria:

      No custom changes to the puppetserver should go into the docker-container's own filesystem (overlay2), but into a persistent volume.

      No custom changes to the puppetserver should go into the docker-container's own filesystem (overlay2), but into a persistent volume.
    • QA Risk Assessment:
      Needs Assessment


      Puppet Server Version: All (the container currently use 7.2.1-1bionic)
      OS Name/Version: Any linux (probably the same problem in Windows)

      This issue concerns puppetserver run as a docker container.

      The project https://github.com/puppetlabs/puppetserver/ does not have its own Issue tracking at github (as pupperware do), so I file this ticket here at tickets.puppetlabs.com instead:

      Just a thought...

      By default r10k uses the path /etc/puppetlabs/r10k/r10k.yaml to look for its conf file.
      However, the path /etc/puppetlabs/r10k/ does not reside in any of the persistent docker volumes for puppetserver. :-/

      If I manually create the dir /etc/puppetlabs/r10k/ and create a conf-file r10k.yaml, and later remove/upgrade the puppetserver container, these changes are lost.

      In the puppetserver image, create a symlink to a sample r10k.yaml file placed in the root of persistent volume 'puppetserver-config' (i.e. next to puppet.conf, puppetdb.conf, etc):

      In the root of volume 'puppetserver-config', create:
        ./r10k.yaml   <-- sample file with all lines commented out
      In the puppetserver image (https://github.com/puppetlabs/puppetserver/blob/6.x/docker/puppetserver/Dockerfile),
        mkdir /etc/puppetlabs/r10k
        ln -s /etc/puppetlabs/puppet/r10k.yaml /etc/puppetlabs/r10k/r10k.yaml

      Desired Behavior:
      Make ones r10k.yaml conf persistent.

      Actual Behavior:
      After the container is removed/updated, the file is gone.

      Example of how I do:
      PS: A possible workaround is to use 'r10k -c' to always point r10k to a custom r10k.yaml file that you have stored anywhere in a persistant volume, but I don't want this. I want to be able to exec into the container and run r10k without any extra options.

      PPS: My r10k fetches stuff from repos using git, which uses ssh. Here too I want things to "work as normal" when I exec into the container and run r10k/git/ssh. This means that I do more symlinks than just the one above.

      Since I need a persistent place to store files, I put them all in a new sub-folder called containerfs-links, to logically separate my "extra files" from the ones that are normally placed in the volume.
      There are three persistent volumes to choose from, I choose puppetserver-config which is mounted at /etc/puppetlabs/puppet.
      So /etc/puppetlabs/puppet/containerfs-links/* is where I place my persistent extra files.
      Here's just an example of the changes I make to the puppetserver image, to get things the way I need:

      # cat Dockerfile
      FROM puppet/puppetserver:7.4.0
      # Add ssh-client so that r10k/git can fetch repos via ssh.
      # Add nano, vim and netcat for when working/debugging within the container.
      RUN echo 'APT::Install-Recommends "0";' > /etc/apt/apt.conf.d/01_no_recommends && \
        apt-get update && \
        apt-get -y install cron openssh-client nano-tiny vim-tiny netcat-openbsd && \
        ln -s /bin/nano-tiny /usr/local/bin/nano && ln -s /usr/bin/vim.tiny /usr/local/bin/vim
      # By default, /etc/puppetlabs/r10k/r10k.yaml is used, but this dir and file don't exist so we create them and point to our persistent place.
      # Prepare symlinks for ssh (git) access to repos.
      RUN mkdir /etc/puppetlabs/r10k && ln -s /etc/puppetlabs/puppet/containerfs-links/r10k.yaml /etc/puppetlabs/r10k/r10k.yaml && \
        mkdir /root/.ssh && ln -s /etc/puppetlabs/puppet/containerfs-links/root/.ssh/id_rsa_for_puppet-master-fetchrepos /root/.ssh/id_rsa && \
        ln -s /etc/puppetlabs/puppet/containerfs-links/root/.ssh/id_rsa.pub_for_puppet-master-fetchrepos /root/.ssh/id_rsa.pub && \
        ln -s /etc/puppetlabs/puppet/containerfs-links/root/.ssh/known_hosts /root/.ssh/known_hosts
      # Let us have our own version of auth.conf and handle the catch22 the very first time the stack is started and our version don't exist yet.
      # This must be executed in the running docker (with the volume mounted), it can't be done with just a symlink directly in the image.
      RUN mkdir /docker-custom-entrypoint.d && echo '#!/bin/bash\n\
      # If our version does not (yet) exist, link to the original so puppetserver can start\n\
      if [ ! -f /etc/puppetlabs/puppet/containerfs-links/puppetserver/conf.d/auth.conf ]; then\n\
        mkdir -p /etc/puppetlabs/puppet/containerfs-links/puppetserver/conf.d\n\
        mv /etc/puppetlabs/puppetserver/conf.d/auth.conf /etc/puppetlabs/puppet/containerfs-links/puppetserver/conf.d/auth.conf\n\
        mv /etc/puppetlabs/puppetserver/conf.d/auth.conf /etc/puppetlabs/puppetserver/conf.d/auth.conf.original_from_container\n\
      ln -s /etc/puppetlabs/puppet/containerfs-links/puppetserver/conf.d/auth.conf /etc/puppetlabs/puppetserver/conf.d/auth.conf' > /docker-custom-entrypoint.d/10-auth.conf.sh
      # Start a cron daemon inside the continer to do tasks like running r10k.
      # Clear all default files installed by the package.
      RUN echo '#!/bin/bash\n\
      rm -f /etc/cron.d/* /etc/cron.daily/* /etc/cron.hourly/* /etc/cron.monthly/* /etc/cron.weekly/*\n\
      echo "SHELL=/bin/sh\nPATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin\n" > /etc/crontab\n\
      echo "#*/5     *       *       *       *       root    /usr/local/bin/run-r10k 2>&1 | /bin/grep -v \"Could not acquire lock. Exiting.\"" >> /etc/crontab\n\
      /usr/sbin/cron' > /docker-custom-entrypoint.d/50-cron.sh
      # More stuff
      RUN chmod 755 /docker-custom-entrypoint.d/* && \
        ...blah... && \




            Unassigned Unassigned
            elof Elof Ofel
            0 Vote for this issue
            2 Start watching this issue



                Zendesk Support