git pull<\/em> command scheduled to run in the Puppet external mount every minute (or so) by cronie<\/li>\nI went with the last approach, but it is probably least appropriate for enterprise or production environments. For me this was suitable, since I’ve decided to install the puppet-agent (no dependencies) from portage (Gentoo’s package manager), but have the master and the pdk run as Docker containers:
\n
\ndocker pull puppet\/puppetserver-standalone
\ndocker pull terzom\/pdk<\/code><\/p>\nRunning the Puppet master from a Docker container is very convenient. The images are tiny. I have created a \/30 network for just the master and the agent to operate in:
\n
\ndocker network create --internal --subnet=192.168.123.0\/30 --gateway 192.168.123.1 puppet-nw
\ndocker run --name puppetmstr --hostname puppetmstr --network puppet-nw -d -v \/work\/puppetlabs:\/etc\/puppetlabs puppet\/puppetserver-standalone<\/code><\/p>\nGladly, the pdk can be run in “disposable” mode (like the ansible container, if you decide to use it) and bind storage to the same config path as the master:
\n
\ndocker run --rm -it -v \/work\/puppetlabs:\/etc\/puppetlabs terzom\/pdk
\n<\/code>
\nThen run pdk to generate templates for a new module. A module is the recommended organizational unit of which files Puppet should control. In most cases people seem to start with NTP as a good, simple example. I’m skipping the interview since I’m not planning to open-source my configs \ud83d\ude09
\n
\npdk new module ntp --skip-interview
\n<\/code><\/p>\nThis generates the schema for the ntp module. Meanwhile, the server needs to be configured to accept connections from the agent (plenty of guides online, I’ll jump over this part) and become authorized to grab files from a clone of the central repo.<\/p>\n
To set up the repo:
\n
\ncd \/work\/puppetlabs\/files;
\ngit init;
\ngit clone ssh:\/\/git@rzski.com:9999\/path\/to\/configs.git
\nchown -R puppet:puppet configs\/
\n<\/code>
\nGOTCHA: all files and folders in the Puppet config as well as cloned from the Git repository need to match the UID and GID used by the Puppet master in the container<\/strong>. Matching the username and group name is not enough, since these are mapped in \/etc\/passwd and \/etc\/group respectively and can have varying octals. Matching them between the host and the container is apparently the recommended approach.
\n
\nThe Puppet master needs to know the location of the central repository pulled from Git. In the below example, I am configuring this directory as a Puppet mount point:
\n
\n# cat \/work\/puppetlabs\/puppet\/fileserver.conf
\n[files]
\n path \/etc\/puppetlabs\/files
\n allow 192.168.123.0\/30<\/code>
\n
\n[configs]
\n path \/etc\/puppetlabs\/files\/configs
\n allow 192.168.123.0\/30
\n<\/code>
\nNote the paths refer to \/etc rather than \/work, since that’s how the master running from within the container will see them.
\nTo configure authorizing the server to access this mount (although it should be enabled by default, I’d rather cut it down to just the participants of my puppet-nw network), the following regexp stanzas are needed (use docker attach puppetmstr<\/em> to hook into the running Puppet master and see how it handles these paths as agents try to connect to it):
\n
\n# cat \/work\/puppetlabs\/puppet\/auth.conf
\n(...)
\n# Authorization for serving files from the Git repo
\npath ~ ^\/file_(metadata|content)s?\/configs\/
\nmethod find
\nallow 192.168.123.0\/30
\npath ~ ^\/file_(metadata|content)s?\/files\/configs\/
\nmethod find
\nallow 192.168.123.0\/30
\n(...)
\n<\/code><\/p>\nNow each time I want to link a file in the central repo with a file in production, be it a script, config, or source code, I need to generate a module for it. Inside each such module, I’m defining a config class to manage the actual config file. The rest of the module code has been pre-populated by pdk<\/em>.
\n
\n# cat \/work\/puppetlabs\/code\/modules\/ntp\/manifests\/config.pp <\/p>\n# ntp::config
\n#
\n# A description of what this class does
\n#
\n# @summary A short summary of the purpose of this class
\n#
\n# @example
\n# include ntp::config
\nclass ntp::config {
\n file { \"ntp.conf\" :
\n path => \"\/etc\/ntp.conf\",
\n owner => \"root\",
\n group => \"root\",
\n mode => \"0644\",
\n source => \"puppet:\/\/\/configs\/ntpd\/ntp.conf\",
\n }
\n}<\/code>
\nIn the above example, the source is defined as Puppet’s fileserver relative location, mount name equals “configs”, and the path is set to ntpd\/ntp.conf to match the config file location in the central config repository pulled from Git.
\n
\nThe Puppet master also needs to know on which nodes (servers) it should manage these config files. In this case, the management happens in the production environment, on the VPS hosting the Puppet master container only – rzski.com<\/strong> (hostname is picked from the host’s \/etc\/hosts):
\n
\n# cat \/work\/puppetlabs\/code\/environments\/production\/manifests\/site.pp
\nnode \"rzski.com\" {
\n include ntp::config
\n}<\/code>
\nThe above two steps (class definition with the correct path and the site.pp class reference per node) would have to be repeated for every module (set of config files or single files or scripts).<\/p>\nTo verify the configs are shared, run the local Puppet binary testing the agent mode:
\n
\n# puppet agent -t
\nInfo: Using configured environment 'production'
\nInfo: Retrieving pluginfacts
\nInfo: Retrieving plugin
\nInfo: Retrieving locales
\nInfo: Caching catalog for rzski.com
\nInfo: Applying configuration version '1543335030'
\nNotice: Applied catalog in 0.05 seconds
\n<\/code>
\nAnd to observe the change commited by appending a comment to the end of the ntp.conf file:
\n
\n# tail \/var\/log\/puppetlabs\/puppet\/puppet.log
\npuppet-agent[18560]: Applied catalog in 0.05 seconds
\npuppet-agent[18728]: (\/Stage[main]\/Ntp::Config\/File[ntp.conf]\/content) content changed '{md5}96db7670882085ea77ce9b5fa14dc46f' to '{md5}06f8cea8589b23e43dcea88cce5ac8ea
\n<\/code><\/p>\nFinally, to “sync” between the Git repo and the Puppet repo, cron can call git pull<\/em> every minute (as described above, optionally that can land in a small shell script). Either switch user to ‘puppet’ and clone (su – puppet -c “git clone…”<\/em>, but this requires giving the puppet user a valid shell, which is not ideal), or just pull && chown.<\/p>\nTo go further from here, I can also execute a command (using Bolt for agentless approach, or a shell script) to, for example, push my Solidity code into my Docker container running Geth Ethereum node. Let’s say I’ve pushed the file from the workstation and accepted the commit. Once the new version gets cloned into the Puppet repo, run docker cp [OPTIONS] SRC_PATH|- CONTAINER:DEST_PATH<\/em>. Then, to register the ABI and, if required, compile, I can chain another task calling docker exec container_name command<\/em> and collect the outputs. But that’s material for another article \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":"In this article I’ll briefly describe how I’m managing my code (configs, scripts, etc.) between my workstation and my virtual private server playground. I will try to point out where I’m using simple solutions instead of enterprise-appropriate ones. To automate the workflow, I am using: Docker – to run services in sandboxed networks, without their […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/patryk.rzski.com\/index.php?rest_route=\/wp\/v2\/posts\/165"}],"collection":[{"href":"https:\/\/patryk.rzski.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/patryk.rzski.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/patryk.rzski.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/patryk.rzski.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=165"}],"version-history":[{"count":18,"href":"https:\/\/patryk.rzski.com\/index.php?rest_route=\/wp\/v2\/posts\/165\/revisions"}],"predecessor-version":[{"id":183,"href":"https:\/\/patryk.rzski.com\/index.php?rest_route=\/wp\/v2\/posts\/165\/revisions\/183"}],"wp:attachment":[{"href":"https:\/\/patryk.rzski.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=165"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/patryk.rzski.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=165"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/patryk.rzski.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=165"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}