Answers: <p>The best stack depends on what environments and platforms your working with, how much standardization you already have, and if your working with open source or not.  If you have the option of using containers for everything then you can simplify the stack and reduce the tool set used.  </p>
  
  <p>The other important note is you are deploying application artifacts and configuration as well as system artifacts and configuration.  Many pipelines use different tools for parts but coordinate with an overall coordinator.  The key is that all the configuration, changes etc are managed in the SCM and are deployed.  </p>
  
  <p>One common open source stack is some flavor of git (Github, Gitlab, etc) along with Jenkins and then ansible for system level configuration and deployment.  This can be used if your using containers or not.  The application deployment capability varies much more as their are more products in the market that specialize in this space so direction competition.  It usually has more to do with the type of application being developed as to which application deployment technology is then used.  </p>
  
  <p>With your stack there is no reason you could not use Git with Jenkins with Kubernetes which which ever cloud you decide to use.  Cloud choice is based on all sorts of factors many that don't have anything to do with technology.  </p>
  
Answers: CC BY-SA 4.0
Answers: 2018-07-12T19:10:46.220Z
Answers: Appreciate your answer.
Answers: Proximo
Answers: CC BY-SA 4.0
Answers: 2018-07-11T12:12:28.897Z
Answers: 2018-07-11T12:12:28.897Z
Answers: Rosalind Radcliffe
Answers: <blockquote>
    <p>Vagrant is for setting up test environments right? Ansible/Chef etc. seem good for servers you own, but what about cloud? Docker... great for standardizing app, so why use Ansible/Chef? Kubernentes.. good for deploying to multiple environments and scaling</p>
  </blockquote>
  
  <p>Just a personal note: the way you formulate these things makes me assume that you are diving freshly into these tools, and trying to figure out what they are for. And your reasoning is "tool X is for purpose Y". I know the feeling, I started out like that as well, trying to wrap my mind around what all this stuff is for. The trap is that the real reasoning should be "tool X does Z", instead. Few of these are really limited to a particular purpose.</p>
  
  <p>For example. You say "Vagrant is for setting up test environments". This is wrong. Vagrant is for spinning up VMs in an automated way, including a zoo of pre-made images. "Ansible is good for servers you own" is wrong. Ansible is a tool to execute commands on a remote server where you have ssh access, with a zoo of recipes/playbooks to do the most common tasks. And so on.</p>
  
  <p>This is not to berate you, but to make it easier for you. Try to be a little less abstract, and just look at what the tool actually <em>does</em>. Then it gets relatively easy to find proper uses, and you also can use the same too for different purposes.</p>
  
  <p>For example:</p>
  
  <p>Vagrant is great for also setting up <em>development</em> environments, not just testing. Or, really, any VM at all where you want the actual content to be mostly configuration-as-code and want to avoid clicking around in a VM GUI.</p>
  
  <blockquote>
    <p>I'm just trying to understand what the need for ansible or chef are? And how about Vagrant?</p>
  </blockquote>
  
  <p>Now you know what the need for Vagrant is.  Vagrant literally solves the need to spin up VMs repeatably, automated, and have the configuration managed as files (i.e., checked into VCS together with the source code of your application, and so on).</p>
  
  <blockquote>
    <p>Also for the build cycle CI/CD pipeline with Git and artifacts.</p>
  </blockquote>
  
  <p>Read the documentation of git &amp; co and actually look at what it <em>does</em>. That, then, is its purpose, nothing more and nothing less. </p>
  
  <p>Same for CI/CD. Continuous integration means <em>literally</em> that. To continuously (i.e., once or more a day, not just every few weeks or months, as it was done in the past) integrate (i.e., merge all the branches of your application that are in development currently). There is no hidden purpose there (or if there is, it should be obvious - doing it more often means every single time is more easy, since there's not such a long time inbetween). Obviously the <em>details</em> of how it works exactly without turning into a nightmare could be more involved, but the <em>purpose</em> is just what it says on the can.</p>
  
  <blockquote>
    <p>AWS, GoogleCloud, Azure ? Which is best</p>
  </blockquote>
  
  <p>It does not make sense to think of "best" here. All three are extremely complex, and the fact that they are all still around means they all serve a purpose. You have to look at each of them, try them out, and compare them to your needs (and your personal likes/dislikes, sometimes).</p>
  
  <blockquote>
    <p>Any recommendations about the best overall Devops setup?</p>
  </blockquote>
  
  <p>Clearly the best overall DevOps setup is the one that solves your problem and fits your overall needs and wishes. There are a vast amount of possibilities of good DevOps setups, and you have to choose for yourself.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-07-06T23:42:57.157Z
Answers: Disappointing answer, suspect you know as little as I do!
Answers: Proximo
Answers: CC BY-SA 4.0
Answers: 2018-07-07T16:58:29.057Z
Answers: @Proximo the fact you dislike an answer doesn't mean it is wrong, using vagrant, packer, gitlab, chef and aws to handle a few apps over undreds of instance for now 3 years. I absolutely agree with AnoE.
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2018-07-07T18:15:13.290Z
Answers: @Tensibai I didn't dislike the answer or down vote it. I was expecting more after reading such a long answer. I can sum up what he wrote in one sentence: All tools are good in different use cases, figure it out yourself. If he would have given examples of use cases for each tool I would have accepted that answer. So following his advice what I'm doing is figuring it out myself and then I'll answer my own question with the results.
Answers: Proximo
Answers: CC BY-SA 4.0
Answers: 2018-07-07T18:40:38.003Z
Answers: I'm tempted to close this question as too broad or opinion based. There's no silver bullet fitting everyone needs, so yes it boils down to experiment and find what you and your team are the more comfortable with. AnoE's answer sched light on what sounded a wrong approach about the tools and as such is the only factual answer possible. There's remarks which may be add, but that's not what SE format works well with.
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2018-07-08T02:21:48.890Z
Answers: Well in that case, I'll just accept AnoE's veiled advice as the answer and keep what I learn to myself. -_-
Answers: Proximo
Answers: CC BY-SA 4.0
Answers: 2018-07-06T19:14:47.693Z
Answers: 2018-07-06T19:14:47.693Z
Answers: AnoE
Body: <p>I'm curious what everyone recommends.</p>
  
  <p>Vagrant is for setting up test environments right? 
  Ansible/Chef etc. seem good for servers you own, but what about cloud?
  Docker... great for standardizing app, so why use Ansible/Chef?
  Kubernentes.. good for deploying to multiple environments and scaling </p>
  
  <p>I'm just trying to understand what the need for ansible or chef are? And how about Vagrant? </p>
  
  <p>Also for the build cycle CI/CD pipeline with Git and artifacts.</p>
  
  <p>Cloud providers:</p>
  
  <p>AWS, GoogleCloud, Azure ? Which is best</p>
  
  <p>Any recommendations about the best overall Devops setup?</p>
  
  <p>Diagram would be best.</p>
  
  <p>Stack is:
  Node, React, MongoDb, Postgres, etc.</p>
  
Comments: CC BY-SA 4.0
Comments: 2018-07-07T00:44:24.340Z
Comments: What works great in one context may be awful in another context. You give little information about your context: what kind/size of software/project/infra, what branching/release model, what team size/maturity/culture, etc - basically what are you trying to achieve?
Comments: Dan Cornilescu
Comments: CC BY-SA 4.0
Comments: 2018-07-07T01:56:42.033Z
Comments: I'm just trying to make sorts of the different tools. I want to know whats best for all situations. I have a PowerEdge in my closet that I fired up today. Cleanly installed Debian Stretch. Specs are 16 core, 64 gig ram. From my laptop, using Chef I deployed Vagrant, Ansible, CFSSL, etc to the server. Then cloned git repo and up'd Vagrant creating an 8 node kubernetes cluster and used Ansible to configure the nodes. My next challege for tonight, weekend.. is to recreate this using AWS, Azure and Google cloud.
Comments: Proximo
Comments: CC BY-SA 4.0
Comments: 2018-07-07T02:04:53.753Z
Comments: My initial thoughts are that Ansible makes scripts easier and reusable. Vagrant is quite powerful easy and fun. And chef seems the most mature. I know my question was vague at best, I just really wanted to to come across an opinionated devops person. After deploying on cloud I deep dive more into Chef as it seems to be the basis for most of these tools. After I master deploying code into Kubernetes from branches, monitoring, logging, testing, and versioning best practices and I'll be satisfied and answer my own question with a repo.
Comments: Proximo
Tags: <docker><amazon-web-services><continuous-integration><kubernetes><deployment>
Title: What's the best complete DevOps setup?
UserDisplayName: Proximo
ThreadText: # What's the best complete DevOps setup?
  
  (Asked by: username_0 on 2018-07-05)
  
  I'm curious what everyone recommends.
  
  Vagrant is for setting up test environments right?
  Ansible/Chef etc. seem good for servers you own, but what about cloud?
  Docker... great for standardizing app, so why use Ansible/Chef?
  Kubernentes.. good for deploying to multiple environments and scaling
  
  I'm just trying to understand what the need for ansible or chef are? And how about Vagrant?
  
  Also for the build cycle CI/CD pipeline with Git and artifacts.
  
  Cloud providers:
  
  AWS, GoogleCloud, Azure ? Which is best
  
  Any recommendations about the best overall Devops setup?
  
  Diagram would be best.
  
  Stack is:
  Node, React, MongoDb, Postgres, etc.
  
  **Tags:** docker, amazon-web-services, continuous-integration, kubernetes, deployment
  
  > **Comments:**
  > **username_1**: What works great in one context may be awful in another context. You give little information about your context: what kind/size of software/project/infra, what branching/release model, what team size/maturity/culture, etc - basically what are you trying to achieve?  
  > **username_0**: I'm just trying to make sorts of the different tools. I want to know whats best for all situations. I have a PowerEdge in my closet that I fired up today. Cleanly installed Debian Stretch. Specs are 16 core, 64 gig ram. From my laptop, using Chef I deployed Vagrant, Ansible, CFSSL, etc to the server. Then cloned git repo and up'd Vagrant creating an 8 node kubernetes cluster and used Ansible to configure the nodes. My next challege for tonight, weekend.. is to recreate this using AWS, Azure and Google cloud.  
  > **username_0**: My initial thoughts are that Ansible makes scripts easier and reusable. Vagrant is quite powerful easy and fun. And chef seems the most mature. I know my question was vague at best, I just really wanted to to come across an opinionated devops person. After deploying on cloud I deep dive more into Chef as it seems to be the basis for most of these tools. After I master deploying code into Kubernetes from branches, monitoring, logging, testing, and versioning best practices and I'll be satisfied and answer my own question with a repo.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2018-07-06. Score: 7 | Accepted answer
  
  > Vagrant is for setting up test environments right? Ansible/Chef etc. seem good for servers you own, but what about cloud? Docker... great for standardizing app, so why use Ansible/Chef? Kubernentes.. good for deploying to multiple environments and scaling
  
  Just a personal note: the way you formulate these things makes me assume that you are diving freshly into these tools, and trying to figure out what they are for. And your reasoning is "tool X is for purpose Y". I know the feeling, I started out like that as well, trying to wrap my mind around what all this stuff is for. The trap is that the real reasoning should be "tool X does Z", instead. Few of these are really limited to a particular purpose.
  
  For example. You say "Vagrant is for setting up test environments". This is wrong. Vagrant is for spinning up VMs in an automated way, including a zoo of pre-made images. "Ansible is good for servers you own" is wrong. Ansible is a tool to execute commands on a remote server where you have ssh access, with a zoo of recipes/playbooks to do the most common tasks. And so on.
  
  This is not to berate you, but to make it easier for you. Try to be a little less abstract, and just look at what the tool actually *does*. Then it gets relatively easy to find proper uses, and you also can use the same too for different purposes.
  
  For example:
  
  Vagrant is great for also setting up *development* environments, not just testing. Or, really, any VM at all where you want the actual content to be mostly configuration-as-code and want to avoid clicking around in a VM GUI.
  
  > I'm just trying to understand what the need for ansible or chef are? And how about Vagrant?
  
  Now you know what the need for Vagrant is. Vagrant literally solves the need to spin up VMs repeatably, automated, and have the configuration managed as files (i.e., checked into VCS together with the source code of your application, and so on).
  
  > Also for the build cycle CI/CD pipeline with Git and artifacts.
  
  Read the documentation of git & co and actually look at what it *does*. That, then, is its purpose, nothing more and nothing less.
  
  Same for CI/CD. Continuous integration means *literally* that. To continuously (i.e., once or more a day, not just every few weeks or months, as it was done in the past) integrate (i.e., merge all the branches of your application that are in development currently). There is no hidden purpose there (or if there is, it should be obvious - doing it more often means every single time is more easy, since there's not such a long time inbetween). Obviously the *details* of how it works exactly without turning into a nightmare could be more involved, but the *purpose* is just what it says on the can.
  
  > AWS, GoogleCloud, Azure ? Which is best
  
  It does not make sense to think of "best" here. All three are extremely complex, and the fact that they are all still around means they all serve a purpose. You have to look at each of them, try them out, and compare them to your needs (and your personal likes/dislikes, sometimes).
  
  > Any recommendations about the best overall Devops setup?
  
  Clearly the best overall DevOps setup is the one that solves your problem and fits your overall needs and wishes. There are a vast amount of possibilities of good DevOps setups, and you have to choose for yourself.
  
  > **Comments:**
  > **username_0**: Disappointing answer, suspect you know as little as I do!  
  > **username_4**: @username_0 the fact you dislike an answer doesn't mean it is wrong, using vagrant, packer, gitlab, chef and aws to handle a few apps over undreds of instance for now 3 years. I absolutely agree with username_3.  
  > **username_0**: @username_4 I didn't dislike the answer or down vote it. I was expecting more after reading such a long answer. I can sum up what he wrote in one sentence: All tools are good in different use cases, figure it out yourself. If he would have given examples of use cases for each tool I would have accepted that answer. So following his advice what I'm doing is figuring it out myself and then I'll answer my own question with the results.  
  > **username_4**: I'm tempted to close this question as too broad or opinion based. There's no silver bullet fitting everyone needs, so yes it boils down to experiment and find what you and your team are the more comfortable with. username_3's answer sched light on what sounded a wrong approach about the tools and as such is the only factual answer possible. There's remarks which may be add, but that's not what SE format works well with.  
  > **username_0**: Well in that case, I'll just accept username_3's veiled advice as the answer and keep what I learn to myself. -_-  
  
  ---
  
  ### Answer by username_2 on 2018-07-11. Score: 4
  
  The best stack depends on what environments and platforms your working with, how much standardization you already have, and if your working with open source or not. If you have the option of using containers for everything then you can simplify the stack and reduce the tool set used.
  
  The other important note is you are deploying application artifacts and configuration as well as system artifacts and configuration. Many pipelines use different tools for parts but coordinate with an overall coordinator. The key is that all the configuration, changes etc are managed in the SCM and are deployed.
  
  One common open source stack is some flavor of git (Github, Gitlab, etc) along with Jenkins and then ansible for system level configuration and deployment. This can be used if your using containers or not. The application deployment capability varies much more as their are more products in the market that specialize in this space so direction competition. It usually has more to do with the type of application being developed as to which application deployment technology is then used.
  
  With your stack there is no reason you could not use Git with Jenkins with Kubernetes which which ever cloud you decide to use. Cloud choice is based on all sorts of factors many that don't have anything to do with technology.
  
  > **Comments:**
  > **username_0**: Appreciate your answer.  
  
  ---
  
  