Answers: <p>So both have their place. On one hand, putting service definitions in the package helps to keep the number of "moving pieces" to a minimum. On the other, it also requires a more complex package build process to at least some degree (like you would have to build your own packages for things instead of using distro packages). If you have the capability to do it in packages, that seems better since moving pieces in prod will always eventually break.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-01T00:13:06.993Z
Answers: 2017-03-01T00:13:06.993Z
Answers: coderanger
Body: <p>We are using Ansible 1.9 for deploying Spring Boot microservices.  We are using CentOS 6 and the services are packaged as rpms. We intend to configure the executable jar files to be supervised by runit, instead of SysVinit or Upstart.</p>
  
  <p>Is it reasonable to package the runit config inside the RPM, and let Ansible only deploy specific properties into <code>/etc/sysconfig</code>, or does a better way to use Ansible for the full runit config exist, so that the service would be decoupled from that host configuration?</p>
  
Tags: <ansible><microservices><runit><spring-boot>
Title: Ansible playbook for configuring runit to supervise an uberjar?
UserDisplayName: ᴳᵁᴵᴰᴼ
ThreadText: # Ansible playbook for configuring runit to supervise an uberjar?
  
  (Asked by: username_0 on 2017-02-28)
  
  We are using Ansible 1.9 for deploying Spring Boot microservices. We are using CentOS 6 and the services are packaged as rpms. We intend to configure the executable jar files to be supervised by runit, instead of SysVinit or Upstart.
  
  Is it reasonable to package the runit config inside the RPM, and let Ansible only deploy specific properties into `/etc/sysconfig`, or does a better way to use Ansible for the full runit config exist, so that the service would be decoupled from that host configuration?
  
  **Tags:** ansible, microservices, runit, spring-boot
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-03-01. Score: 3
  
  So both have their place. On one hand, putting service definitions in the package helps to keep the number of "moving pieces" to a minimum. On the other, it also requires a more complex package build process to at least some degree (like you would have to build your own packages for things instead of using distro packages). If you have the capability to do it in packages, that seems better since moving pieces in prod will always eventually break.
  
  
  ---
  
  