Answers: <p><strong>TL;DR</strong> Roll out a container orchestrator for new builds (e.g. OKD or the commercial version OCP). Work on packaging existing apps to be managed by an automation system (e.g., Puppet Enterprise) so rollout, patching and upgrades are all automated. Take root access away from everyone else and have them only do installs via the automation tools. </p>
  
  <p><strong>Long Answer</strong> including one fully automated WMWare private cloud: </p>
  
  <p>Moving to cloud native tech such as Kubernetes, CloudFoundry or Docker Swarm isn't an easy option if you have a huge set it existing apps. Yet you could potentially reap huge benefits from making such technology available for new development. What you want is for teams to "self-service" via, say, the Kubernetes webui and command line tools. OKD is a distro of Kubernetes that focuses on “self-service devops” that I have seen work very well for three large system builds at three large organisations. It can be installed on Linux VMs that you manage any way you want (e.g., Puppet Enterprise example below) and there is commercial support from a large Linux vendor. </p>
  
  <p>With such an approach you setup a cluster you can expand to up to 2000 identical VMs. You grant teams a logical “namespace” (aka “project”) and assign a quota for memory and cpu. Teams then use the webui or command line to spin up dozens of containers that are automatically spread over the cluster of VMs. You can apply tags to VMs and projects to place different teams on different pools of VMs if you still want bill departments based on how many VMs they reserve. OKD does software defined networks and automated DNS for each project so it takes away the headaches of assigning IPs or managing DNS as it is fully automated. Also load balancing, fail-overs and scale out are all automated. It also does rolling deployments and will health check containers and restart failed ones. </p>
  
  <p>New apps will need to be built to modern standards to work within such a container orchestrator. In four separate experiences of rolling this out I have seen skeptical developer teams love the immediacy of "just help ourselves" up to their quota. The forget they ever started out demanding root access. I worked at a big organisation where we automated setting up each new scrum team with with multiple environments on commercial OKD (called OCP) with databases, networks, git repos, and running sample code all created by a small webapp we wrote in less than 15 minutes. </p>
  
  <p>With your existing stuff then the road out of cost and overhead is standardisation, standardisation and more standardisation. At the moment I am working with a private cloud platform which is VMWare vRA based. The vRA portal has blueprint that internal customers launch standardised host profiles for databases, message brokers, webservers and "vanilla” (plain) Linux hosts. The launched images have Puppet Agent installed and a Puppet Enterprise Server enforces, you guessed it, standards. If you use root to tamper with the config then puppet agent runs every 20 minutes and puts back the configuration to match the puppet profile. </p>
  
  <p>The puppet profiles are all in git and a separate Puppet Hiera config repo defines all configuration setting for all hosts. One git repo has the Hiera config for the base OS with different overrides for database profiles or application profiles (eg applying kernel settings). A second git repo holds the Hiera config for the application profiles (e.g., install and start oracle database, or a message brokers, or a web server). A third repo holds the Hiera config for any host level overrides needs for tricky applications or production fixes yet to make it into the main configuration for that application profile. </p>
  
  <p>Puppet chooses the most specific configuration settings for the actual hosts. It looks for host specific, not normally needed, then looks for app profile specific settings, not always defined, then uses the default for the OS. Everything is in git and managed by code review of pull requests. It’s proper infrastructure-as-code managed by GitHub Enterprise. </p>
  
  <p>All of the above works for the “standard” software packages used at the organisation. For in-house apps they don’t yet have Kubernetes. Teams launch a “vanilla” Linux blueprint on the VMware vRA portal rather than a specific application blue print. So they might launch an Oracle database blueprint and three vanilla Linux ones to run their java code. With vanilla it has all the access management packages (Centify) and teams just run use scp to upload their java. Teams are using Ansible Tower to upload their Java apps via none root ssh access. That is driven by Jenkins deploy jobs that call out to Ansible Tower.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-01-10T08:19:28.240Z
Answers: 2019-01-10T20:58:57.370Z
Answers: 2019-01-10T20:58:57.370Z
Answers: simbo1905
Answers: <p>I suggest <a href="https://www.terraform.io/" rel="nofollow noreferrer">terraform</a>. A lot of companies are using it and this tool is basically one of the industry standard. This tool is basically an acronym for infrastructure-as-code.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-01-12T16:32:35.653Z
Answers: 2019-01-12T16:32:35.653Z
Answers: 030
Answers: <p>The answer will depend on how much you want to change. I will describe how most larger companies solves this nowadays.</p>
  
  <p>Containerize the apps. Run them in <a href="https://www.docker.com/" rel="nofollow noreferrer">Docker</a> containers. And use a container orchestration tool, like <a href="https://kubernetes.io/" rel="nofollow noreferrer">Kubernetes</a> to manage deployment. But to do this your application must probably be redesigned to follow <a href="https://12factor.net/" rel="nofollow noreferrer">The Twelve factor methodology</a>.</p>
  
  <p>Both Amazon, Azure and Google have Kubernetes cloud services. If you want to continue with private cloud, <a href="https://www.openshift.com/" rel="nofollow noreferrer">OpenShift</a> is the most popular Kubernetes-product.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-01-08T17:29:50.060Z
Answers: 2019-01-08T17:29:50.060Z
Answers: Jonas
Body: <p>I manage a set of virtual servers in a private cloud on vSphere.</p>
  
  <p>In this private cloud we have several sets of servers that host several web applications such as:</p>
  
  <p>-Webpress web sites</p>
  
  <p>-Phone applications in PHP</p>
  
  <p>-Java web applications</p>
  
  <p>-Alfresco</p>
  
  <p>-Redmine</p>
  
  <p>-Nagios</p>
  
  <p>-Jenkins</p>
  
  <p>-Odoo</p>
  
  <p>And these applications are hosted in separate servers with an architecture that mixes several technologies:</p>
  
  <p>-firewall</p>
  
  <p>-reverse proxy / loadbalancer / SSL termination (Haproxy)</p>
  
  <p>-caching servers</p>
  
  <p>-web servers</p>
  
  <p>-LDAP directory server</p>
  
  <p>-Server to centralize the backup and send it to remote NAS</p>
  
  <p>We have a problem of complexity to manage these applications as each application has a VM server that hosts it and another that contains its database and another that saves the data ..etc</p>
  
  <p>What do you recommend to me as tools to make my life easier, on <strong>deployment</strong>, <strong>automation</strong>, <strong>maintenance</strong>, <strong>organization of applications</strong>, <strong>security</strong></p>
  
  <p>And on everything how to <strong>organize and save my configurations for each server</strong> ... etc</p>
  
  <p><strong><em>Do you recommend another architecture or solution?</em></strong></p>
  
Tags: <deployment><continuous-deployment><configuration-management><cloud>
Title: What are the tools you recommend for deploying / automating / organizing vm in the private cloud
UserDisplayName: tmedtcom
ThreadText: # What are the tools you recommend for deploying / automating / organizing vm in the private cloud
  
  (Asked by: username_0 on 2019-01-08)
  
  I manage a set of virtual servers in a private cloud on vSphere.
  
  In this private cloud we have several sets of servers that host several web applications such as:
  
  -Webpress web sites
  
  -Phone applications in PHP
  
  -Java web applications
  
  -Alfresco
  
  -Redmine
  
  -Nagios
  
  -Jenkins
  
  -Odoo
  
  And these applications are hosted in separate servers with an architecture that mixes several technologies:
  
  -firewall
  
  -reverse proxy / loadbalancer / SSL termination (Haproxy)
  
  -caching servers
  
  -web servers
  
  -LDAP directory server
  
  -Server to centralize the backup and send it to remote NAS
  
  We have a problem of complexity to manage these applications as each application has a VM server that hosts it and another that contains its database and another that saves the data ..etc
  
  What do you recommend to me as tools to make my life easier, on **deployment**, **automation**, **maintenance**, **organization of applications**, **security**
  
  And on everything how to **organize and save my configurations for each server** ... etc
  
  ***Do you recommend another architecture or solution?***
  
  **Tags:** deployment, continuous-deployment, configuration-management, cloud
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2019-01-10. Score: 0 | Accepted answer
  
  **TL;DR** Roll out a container orchestrator for new builds (e.g. OKD or the commercial version OCP). Work on packaging existing apps to be managed by an automation system (e.g., Puppet Enterprise) so rollout, patching and upgrades are all automated. Take root access away from everyone else and have them only do installs via the automation tools.
  
  **Long Answer** including one fully automated WMWare private cloud:
  
  Moving to cloud native tech such as Kubernetes, CloudFoundry or Docker Swarm isn't an easy option if you have a huge set it existing apps. Yet you could potentially reap huge benefits from making such technology available for new development. What you want is for teams to "self-service" via, say, the Kubernetes webui and command line tools. OKD is a distro of Kubernetes that focuses on “self-service devops” that I have seen work very well for three large system builds at three large organisations. It can be installed on Linux VMs that you manage any way you want (e.g., Puppet Enterprise example below) and there is commercial support from a large Linux vendor.
  
  With such an approach you setup a cluster you can expand to up to 2000 identical VMs. You grant teams a logical “namespace” (aka “project”) and assign a quota for memory and cpu. Teams then use the webui or command line to spin up dozens of containers that are automatically spread over the cluster of VMs. You can apply tags to VMs and projects to place different teams on different pools of VMs if you still want bill departments based on how many VMs they reserve. OKD does software defined networks and automated DNS for each project so it takes away the headaches of assigning IPs or managing DNS as it is fully automated. Also load balancing, fail-overs and scale out are all automated. It also does rolling deployments and will health check containers and restart failed ones.
  
  New apps will need to be built to modern standards to work within such a container orchestrator. In four separate experiences of rolling this out I have seen skeptical developer teams love the immediacy of "just help ourselves" up to their quota. The forget they ever started out demanding root access. I worked at a big organisation where we automated setting up each new scrum team with with multiple environments on commercial OKD (called OCP) with databases, networks, git repos, and running sample code all created by a small webapp we wrote in less than 15 minutes.
  
  With your existing stuff then the road out of cost and overhead is standardisation, standardisation and more standardisation. At the moment I am working with a private cloud platform which is VMWare vRA based. The vRA portal has blueprint that internal customers launch standardised host profiles for databases, message brokers, webservers and "vanilla” (plain) Linux hosts. The launched images have Puppet Agent installed and a Puppet Enterprise Server enforces, you guessed it, standards. If you use root to tamper with the config then puppet agent runs every 20 minutes and puts back the configuration to match the puppet profile.
  
  The puppet profiles are all in git and a separate Puppet Hiera config repo defines all configuration setting for all hosts. One git repo has the Hiera config for the base OS with different overrides for database profiles or application profiles (eg applying kernel settings). A second git repo holds the Hiera config for the application profiles (e.g., install and start oracle database, or a message brokers, or a web server). A third repo holds the Hiera config for any host level overrides needs for tricky applications or production fixes yet to make it into the main configuration for that application profile.
  
  Puppet chooses the most specific configuration settings for the actual hosts. It looks for host specific, not normally needed, then looks for app profile specific settings, not always defined, then uses the default for the OS. Everything is in git and managed by code review of pull requests. It’s proper infrastructure-as-code managed by GitHub Enterprise.
  
  All of the above works for the “standard” software packages used at the organisation. For in-house apps they don’t yet have Kubernetes. Teams launch a “vanilla” Linux blueprint on the VMware vRA portal rather than a specific application blue print. So they might launch an Oracle database blueprint and three vanilla Linux ones to run their java code. With vanilla it has all the access management packages (Centify) and teams just run use scp to upload their java. Teams are using Ansible Tower to upload their Java apps via none root ssh access. That is driven by Jenkins deploy jobs that call out to Ansible Tower.
  
  
  ---
  
  ### Answer by username_2 on 2019-01-12. Score: 0
  
  I suggest [terraform](https://www.terraform.io/). A lot of companies are using it and this tool is basically one of the industry standard. This tool is basically an acronym for infrastructure-as-code.
  
  
  ---
  
  ### Answer by username_3 on 2019-01-08. Score: 0
  
  The answer will depend on how much you want to change. I will describe how most larger companies solves this nowadays.
  
  Containerize the apps. Run them in [Docker](https://www.docker.com/) containers. And use a container orchestration tool, like [Kubernetes](https://kubernetes.io/) to manage deployment. But to do this your application must probably be redesigned to follow [The Twelve factor methodology](https://12factor.net/).
  
  Both Amazon, Azure and Google have Kubernetes cloud services. If you want to continue with private cloud, [OpenShift](https://www.openshift.com/) is the most popular Kubernetes-product.
  
  
  ---
  
  