{"id":617,"date":"2017-02-09T00:49:38","date_gmt":"2017-02-08T23:49:38","guid":{"rendered":"https:\/\/www.dereckson.be\/blog\/?p=617"},"modified":"2017-03-01T22:22:08","modified_gmt":"2017-03-01T21:22:08","slug":"deploy-a-darkbot-or-a-simple-generic-service-with-saltstack-part-2","status":"publish","type":"post","link":"https:\/\/www.dereckson.be\/blog\/2017\/02\/09\/deploy-a-darkbot-or-a-simple-generic-service-with-saltstack-part-2\/","title":{"rendered":"Deploy a darkbot or a simple generic service with SaltStack (part 2)"},"content":{"rendered":"

This is the part 2 of our service deployment walkthrough.
\nSee also: Part 1 \u2014 Service accounts, sudo capabilities<\/a><\/em><\/p>\n

In the first part<\/a>, we’ve seen how to create an user account for the service, a group to put users with access to the service into, and sudo capabilities to allow full control on the service account, some control as root to interact with systemd or another service manager.<\/p>\n

Deploy an application through package<\/h2>\n

If your application is packaged or you package it, something we recommend hearthily, you can simply the pkg.installed<\/a> state.<\/p>\n

For example if you wish to deploy with this state configuration:<\/p>\n

odderon_packages:\r\n  pkg:\r\n    - installed\r\n    - pkgs:\r\n      - darkbot\r\n      - darkbot-backup-manager\r\n<\/pre>\n
If you only have one application you installed, you can omit pkgs, it will then take the state name:<\/p>\n
darkbot:\r\n  pkg.installed\r\n<\/pre>\n
If you want to force the last version to be reinstalled when you run again the state, you can instead use pkg.latest<\/a>:<\/p>\n
darkbot:\r\n  pkg.latest\r\n<\/pre>\n
Salt can then take care of your upgrade process.<\/p>\n
Deploy an application fetching and building it<\/h2>\n
In this sample, we’ll fetch the source code from the last version of the production<\/code> branch of a Git repository cloned at \/usr\/local\/src\/darkbot<\/code>, and we’ll install the software to \/opt\/odderon<\/code>. To use \/opt<\/code> will allow us to perform an installation process running as a non privileged user.<\/p>\n
Fetch the source code<\/h3>\n
Sometimes, you want a workflow to fetch, build, install, to have a better control on the compilation. Docker image creators tend to like to automate build processes.<\/p>\n
For that, you need two things:<\/p>\n
    \n
  1. A directory where to clone the software<\/li>\n
  2. To actually clone the repository<\/li>\n<\/ol>\n
    A same Salt state can call several functions, here one from file<\/strong> to create a directory (file.directory<\/strong>) and one from git<\/strong> to clone (git.latest<\/strong>):<\/p>\n
    darkbot_repo:\r\n  file.directory:\r\n    - name: \/usr\/local\/src\/darkbot\r\n    - user: odderon\r\n    - group: nasqueron-irc\r\n    - dir_mode: 755\r\n  git.latest:\r\n    - name: https:\/\/devcentral.nasqueron.org\/source\/darkbot.git\r\n    - branch: production\r\n    - target: \/usr\/local\/src\/darkbot\r\n    - user: odderon\r\n<\/pre>\n
    We’ve reused the user and group created in previous part.<\/p>\n
    To clone the repository, we recommend to do the clone from a source you can trust (e.g. PHP provides GPG signed packages) or better, a source you control.<\/p>\n
    Note it’s currently not possible to call two functions from the same module, e.g. two git or two file wouldn’t work.<\/p>\n
    If you automate the upgrade process (something best to do only if your CI\/CD infrastructure tests the Salt deployment), provide your deployers a quick way to stop the update process.<\/p>\n
    For example, you can provide a lock file in the application directory (here \/opt\/odderon):<\/p>\n
    \u2026:\r\n  \u2026\r\n  git.latest:\r\n    - name: https:\/\/devcentral.nasqueron.org\/source\/darkbot.git\r\n    - branch: production\r\n    - target: \/usr\/local\/src\/darkbot\r\n    - user: odderon\r\n    - unless: test -f \/opt\/odderon\/LOCKED\r\n<\/pre>\n
    If the file exists, state will be skipped, so it’s as simple as touch \/opt\/odderon\/LOCKED<\/code> to pause deployment, rm \/opt\/odderon\/LOCKED<\/code> to resume it. SaltStack has a good documentation about requisites<\/a>, requisites not always intuitive.<\/p>\n
    Compile<\/h3>\n
    Let’s start with a simple case where you only have one command to write to configure, compile, install, for example here: .\/build.sh --with-sleep=0 --with-add=0 --with-del=0 --with-random=0 --destdir=\/opt\/odderon<\/code>.<\/p>\n
    For that, you only need cmd.run<\/a>:<\/p>\n
    darkbot_build:\r\n  cmd.run:\r\n    - name: .\/build.sh\r\n    - args: \"--with-sleep=0 --with-add=0 --with-del=0 --with-random=0 --destdir=\/opt\/odderon\"\r\n    - cwd: \/usr\/local\/src\/darkbot\r\n    - runas: odderon\r\n<\/pre>\n
    The cwd<\/code> parameter allows to change the working directory (cd \/usr… ; .\/build.sh…) and runas<\/code> to run the command as another user than root.<\/p>\n
    If you don’t have such script available, just create it<\/a>.<\/p>\n
    Salt allows to deploy a custom script before to run it in one step with the cmd.script<\/a> command:<\/p>\n
    darkbot_build:\r\n  cmd.script:\r\n    - source: salt:\/\/roles\/shellserver\/odderon\/files\/build.sh\r\n    - args: \"--with-sleep=0 --with-add=0 --with-del=0 --with-random=0\"\r\n    - cwd: \/usr\/local\/src\/darkbot\r\n    - runas: odderon\r\n<\/pre>\n
    The roles\/shellserver\/odderon\/files\/build.sh<\/code> file will be copied on the server, and run, and yes you can also send arguments to the script like with cmd.run.<\/p>\n
    This process isn’t useful if Git failed, so we can require another state succeeded:<\/p>\n
    darkbot_build:\r\n  cmd.script:\r\n    - source: salt:\/\/roles\/shellserver\/odderon\/files\/build.sh\r\n    - args: \"--with-sleep=0 --with-add=0 --with-del=0 --with-random=0\"\r\n    - cwd: \/usr\/local\/src\/darkbot\r\n    - runas: odderon\r\n    - require:\r\n        - git: darkbot_repo\r\n<\/pre>\n
    The same process can be used to provide the service configuration. For example, to copy a hierarchy of files from your Salt root directory to the server:<\/p>\n
    darkbot_configuration:\r\n  file.recurse:\r\n    - name: \/opt\/odderon\/dat\r\n    - source: salt:\/\/roles\/shellserver\/odderon\/files\/dat\r\n    - dir_mode: 770\r\n    - file_mode: 640\r\n<\/pre>\n
    The 770 directory mode will allow the service and the deployers to access it, files by default read only for deployers to encourage to use Salt to edit them.<\/p>\n
    By the way, you probably also want a warning like this:<\/p>\n
    #   <auto-generated>\r\n#       This file is managed by our rOPS repository\r\n#       and deployed through SaltStack.\r\n#\r\n#       Changes to this file may cause incorrect behavior\r\n#       and will be lost if the state is redeployed.\r\n# \r\n#       Source directory: roles\/shellserver\/odderon\/files\/dat\r\n#   <\/auto-generated><\/pre>\n
    It’s then clear when you’re on the production server a file opened is managed.<\/p>\n
    Upgrade the code<\/h3>\n
    So, what can you do with that?<\/p>\n
    First, it can provision your service to a new server, but you can also use it for updat. For example, if you’ve your states in roles\/shellserver\/odderon\/init.sls, you can upgrade with:<\/p>\n
    salt eglide state.apply roles\/shellserver\/odderon<\/code><\/p>\n
    It will then upgrade your package or fetch the latest Git commit and recompile your code.<\/p>\n
    If you compile manually, note the build script doesn’t especially need a clean step. For example, if you use a Makefile, make will detect your file has been modified (looking the timestamp) and so should be upgraded.<\/p>\n
    Create a service<\/h2>\n
    Thanks to Sandlayth<\/a> to have prepared the Salt configuration for this part.<\/em><\/p>\n
    If your application doesn’t provide a service, it’s valuable to create one.<\/p>\n
    Two steps are needed: deploy the service file, ensure the service runs. For systemd, a third step is needed to force reload configuration.<\/p>\n
    The first part is service manager dependant, the second part is service manager agnostic.<\/p>\n
    odderon_service:\r\n  file.managed:\r\n    - name: \/usr\/local\/etc\/rc.d\/odderon\r\n    - source: salt:\/\/roles\/shellserver\/odderon\/files\/odderon.rc\r\n    - mode: 0755\r\n<\/pre>\n
    We told you there is an extra step for systemd. This one is tricky: as this is a command to refresh an application knowledge, that’s not something we can declare and check, so it’s not available as a state. SaltStack also allows to run commands, and provide modules for that. For example, you can do salt eglide service.force_reload odderon<\/code> (see systemd module doc<\/a>, right menu offers the same for other systems).<\/p>\n
    odderon_service:\r\n  file.managed:\r\n    - name: \/etc\/systemd\/system\/odderon.service\r\n    - source: salt:\/\/roles\/shellserver\/odderon\/files\/odderon.service\r\n    - mode: 0644\r\n  module.run:\r\n    - name: service.force_reload\r\n    - m_name: odderon\r\n    - onchanges:\r\n       - file: odderon_unit\r\n<\/pre>\n
    Parameters for the module you run are directly put after the name. But here service.force_reload<\/code> has also a name<\/code> parameter. To disambiguate, you prepend m_<\/code> and get m_name<\/code>.<\/p>\n
    There is currently in Salt a work of progress to abstract more the services.<\/p>\n
    Finally, whatever the service manager, you want to ensure the service runs<\/a>:<\/p>\n
    odderon_running:\r\n  service.running:\r\n    - name: odderon\r\n    - enable: true\r\n    - watch:\r\n      - module: odderon_service\r\n<\/pre>\n
    The enable<\/code> parameter is useful if you use a systemd-like service, as the service must be explicitly enabled to be automatically launched at server start time.<\/p>\n","protected":false},"excerpt":{"rendered":"
    This is the part 2 of our service deployment walkthrough. See also: Part 1 \u2014 Service accounts, sudo capabilities In the first part, we’ve seen how to create an user account for the service, a group to put users with access to the service into, and sudo capabilities to allow full control on the service […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[50],"tags":[294,296,221,298],"class_list":["post-617","post","type-post","status-publish","format-standard","hentry","category-sysadmin","tag-darkbot","tag-eglide","tag-saltstack","tag-systemd"],"_links":{"self":[{"href":"https:\/\/www.dereckson.be\/blog\/wp-json\/wp\/v2\/posts\/617","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dereckson.be\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dereckson.be\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dereckson.be\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dereckson.be\/blog\/wp-json\/wp\/v2\/comments?post=617"}],"version-history":[{"count":17,"href":"https:\/\/www.dereckson.be\/blog\/wp-json\/wp\/v2\/posts\/617\/revisions"}],"predecessor-version":[{"id":658,"href":"https:\/\/www.dereckson.be\/blog\/wp-json\/wp\/v2\/posts\/617\/revisions\/658"}],"wp:attachment":[{"href":"https:\/\/www.dereckson.be\/blog\/wp-json\/wp\/v2\/media?parent=617"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dereckson.be\/blog\/wp-json\/wp\/v2\/categories?post=617"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dereckson.be\/blog\/wp-json\/wp\/v2\/tags?post=617"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}