petardenev · June 28, 2019 13:20
diff --git a/building-devops b/building-devops
 Situation 1:   New project, DevOps engineer starts building the solution from scratch, his workflow should stick with the logic below:

 1.1 Cloud-Platform independence  achieved with use of:
      Linux -  masterless Puppet/Chef-solo/SALT-masterless/Ansible
      Windows - Powershell DSC/ WinRM/ Аpache Brooklyn
  
 1.2 Have a control script, eg. bash or powershell, it will automate use of the Puppet modules/DSC Configurations, cluster configurations, hostnames, etc things needed for implementation before having а running application stack(AppStack here is to be considered as separate Development Environment, it can be DEV/QA/PROD/ETC)
 1.3 Have the CI/CD software solution done with package deployment, e.g. the software is to be delivered to the servers as rpm/deb package and installed from a repository, for example Sonatype Nexus OSS https://www.sonatype.com/nexus-repository-oss can store and distribute Maven/Java, npm, NuGet, RubyGems, Docker, P2, OBR, APT and YUM.
 1.4 Minimize usage of public IP addresses or any IP addresses at all, you should connect to all applications via DNS name, no matter if its in /etc/hosts even,
 1.5 Introduce service granularity, run each separate application service in different instance/container, this way you’ll be able to easy dispose of instances, without interfering with the other services in the ApplicationStack, you’l be able to update them, recycle, autoscale autonomously
 1.6 Implement the possibility to easy update packages on already running application stacks, based on DNS name and/or other marks to achieve true immutable infrastructure
 1.7 Create a self-healing immutable infrastructure to completely remove the human factor for management and/or monitoring. This is achieved by using Consul [consul.io] or Apache Zookeeper or  Hashicorp Serf, monit, keepalived,et
 1.8 In order to retain real security on the customers data/software, the AppStack should be publicly accessed only via a LoadBalancer. It doesn’t matter the type of LB that is used, each cloud provider has its own technologies and products that provide this functionality.
 1.9 Most important is to use such, as this will guarantee you independency, exposing only the needed ports to the LB, retaining the rest of the ports used in the application closed to the world and adding another layer of security, without paying more for the service.
 1.10 Support the DevOps Community 

 Situation 2:   Inherited project, DevOps engineer must build the solution on-top of already running infrastructure

 2.1 Reverse-engineer each server configurations
    Linux – implement the use of https://github.com/petardenev/blueprint , generate puppet modules and manifests out of the already built servers
    Windows – implement the use of https://github.com/petardenev/dsc-generator , generate the DSC configuration for future use
    
 2.2 Have a control script, eg. bash or powershell, it will automate use of the Puppet modules/DSC Configurations, cluster configurations, hostnames, etc things needed for implementation before having а running application stack(AppStack here is to be considered as separate Development Environment, it can be DEV/QA/PROD/ETC)
 2.3 Have the CI/CD software solution done with package deployment, e.g. the software is to be delivered to the servers as rpm/deb package and installed from a repository, for example Sonatype Nexus OSS https://www.sonatype.com/nexus-repository-oss can store and distribute Maven/Java, npm, NuGet, RubyGems, Docker, P2, OBR, APT and YUM.
 2.4 Minimize usage of public IP addresses or any IP addresses at all, you should connect to all applications via DNS name, no matter if its in /etc/hosts even,
 2.5 Introduce service granularity, run each separate application service in different instance/container, this way you’ll be able to easy dispose of instances, without interfering with the other services in the ApplicationStack, you’l be able to update them, recycle, autoscale autonomously
 2.6 Implement the possibility to easy update packages on already running application stacks, based on DNS name and/or other marks to achieve true immutable infrastructure
 2.7 Create a self-healing immutable infrastructure to completely remove the human factor for management and/or monitoring. This is achieved by using Consul [consul.io] or Apache Zookeeper or  Hashicorp Serf, monit, keepalived,etc 
 2.8 In order to retain real security on the customers data/software, the AppStack should be publicly accessed only via a LoadBalancer. It doesn’t matter the type of LB that is used, each cloud provider has its own technologies and products that provide this functionality. Most important is to use such, as this will guarantee you independency, exposing only the needed ports to the LB, retaining the rest of the ports used in the application closed to the world and adding another layer of security, without paying more for the service.
 2.9 Most important is to use such, as this will guarantee you independency, exposing only the needed ports to the LB, retaining the rest of the ports used in the application closed to the world and adding another layer of security, without paying more for the service.
 2.10 Support the DevOps Community
	Situation 1: New project, DevOps engineer starts building the solution from scratch, his workflow should stick with the logic below:

	1.1 Cloud-Platform independence achieved with use of:
	Linux - masterless Puppet/Chef-solo/SALT-masterless/Ansible
	Windows - Powershell DSC/ WinRM/ Аpache Brooklyn

	1.2 Have a control script, eg. bash or powershell, it will automate use of the Puppet modules/DSC Configurations, cluster configurations, hostnames, etc things needed for implementation before having а running application stack(AppStack here is to be considered as separate Development Environment, it can be DEV/QA/PROD/ETC)
	1.3 Have the CI/CD software solution done with package deployment, e.g. the software is to be delivered to the servers as rpm/deb package and installed from a repository, for example Sonatype Nexus OSS https://www.sonatype.com/nexus-repository-oss can store and distribute Maven/Java, npm, NuGet, RubyGems, Docker, P2, OBR, APT and YUM.
	1.4 Minimize usage of public IP addresses or any IP addresses at all, you should connect to all applications via DNS name, no matter if its in /etc/hosts even,
	1.5 Introduce service granularity, run each separate application service in different instance/container, this way you’ll be able to easy dispose of instances, without interfering with the other services in the ApplicationStack, you’l be able to update them, recycle, autoscale autonomously
	1.6 Implement the possibility to easy update packages on already running application stacks, based on DNS name and/or other marks to achieve true immutable infrastructure
	1.7 Create a self-healing immutable infrastructure to completely remove the human factor for management and/or monitoring. This is achieved by using Consul [consul.io] or Apache Zookeeper or Hashicorp Serf, monit, keepalived,et
	1.8 In order to retain real security on the customers data/software, the AppStack should be publicly accessed only via a LoadBalancer. It doesn’t matter the type of LB that is used, each cloud provider has its own technologies and products that provide this functionality.
	1.9 Most important is to use such, as this will guarantee you independency, exposing only the needed ports to the LB, retaining the rest of the ports used in the application closed to the world and adding another layer of security, without paying more for the service.
	1.10 Support the DevOps Community

	Situation 2: Inherited project, DevOps engineer must build the solution on-top of already running infrastructure

	2.1 Reverse-engineer each server configurations
	Linux – implement the use of https://github.com/petardenev/blueprint , generate puppet modules and manifests out of the already built servers
	Windows – implement the use of https://github.com/petardenev/dsc-generator , generate the DSC configuration for future use

	2.2 Have a control script, eg. bash or powershell, it will automate use of the Puppet modules/DSC Configurations, cluster configurations, hostnames, etc things needed for implementation before having а running application stack(AppStack here is to be considered as separate Development Environment, it can be DEV/QA/PROD/ETC)
	2.3 Have the CI/CD software solution done with package deployment, e.g. the software is to be delivered to the servers as rpm/deb package and installed from a repository, for example Sonatype Nexus OSS https://www.sonatype.com/nexus-repository-oss can store and distribute Maven/Java, npm, NuGet, RubyGems, Docker, P2, OBR, APT and YUM.
	2.4 Minimize usage of public IP addresses or any IP addresses at all, you should connect to all applications via DNS name, no matter if its in /etc/hosts even,
	2.5 Introduce service granularity, run each separate application service in different instance/container, this way you’ll be able to easy dispose of instances, without interfering with the other services in the ApplicationStack, you’l be able to update them, recycle, autoscale autonomously
	2.6 Implement the possibility to easy update packages on already running application stacks, based on DNS name and/or other marks to achieve true immutable infrastructure
	2.7 Create a self-healing immutable infrastructure to completely remove the human factor for management and/or monitoring. This is achieved by using Consul [consul.io] or Apache Zookeeper or Hashicorp Serf, monit, keepalived,etc
	2.8 In order to retain real security on the customers data/software, the AppStack should be publicly accessed only via a LoadBalancer. It doesn’t matter the type of LB that is used, each cloud provider has its own technologies and products that provide this functionality. Most important is to use such, as this will guarantee you independency, exposing only the needed ports to the LB, retaining the rest of the ports used in the application closed to the world and adding another layer of security, without paying more for the service.
	2.9 Most important is to use such, as this will guarantee you independency, exposing only the needed ports to the LB, retaining the rest of the ports used in the application closed to the world and adding another layer of security, without paying more for the service.
	2.10 Support the DevOps Community