We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Beyond the Cookbook: Using Workflow to Bring Continuous Delivery to And Project

00:00

Formal Metadata

Title
Beyond the Cookbook: Using Workflow to Bring Continuous Delivery to And Project
Title of Series
Number of Parts
45
Author
License
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
While we all know workflow provides an easy way to do continuous integration/delivery for cookbooks, we also all have other parts that need to be developed and maintained for a successful DevOps environment. This talk will provide information on how to extend the power of delivery to those other projects, and provide the basics needed to understand creating build cookbooks well enough to create one for any project. Topics covered: Understanding the build cookbook, what the phases of the build cookbook are, and how workflow uses them. Using dependencies to tie together both cookbook and non-cookbook items. Demo: Using workflow to build a small web application including building the Web server from source, and delivering to an end environment.
Continuous functionInformation securityInformationLie groupProgrammable read-only memoryThomas KuhnProjective planeArithmetic meanPresentation of a groupSpacetimeIndependence (probability theory)JSONXMLUMLComputer animation
Continuous integrationDisintegrationBuildingMereologyAutomationNormal (geometry)Standard deviationDefault (computer science)Phase transitionContinuous integrationAutomationDirectory serviceCodeProjective planeMereologyNormal (geometry)Electric generatorPhase transitionDefault (computer science)Analytic continuationINTEGRALKey (cryptography)
Phase transitionFormal verificationExecution unitSoftware testingCodeError messageLocal ringServer (computing)Functional (mathematics)Integrated development environmentClient (computing)BuildingRevision controlServer (computing)Projective planeSoftware testingPhase transitionExecution unitRevision controlLevel (video gaming)CodeSubsetIntegrated development environmentNumberLocal ringNetwork topologyClient (computing)MathematicsBuildingInformation securityConfiguration spaceLogic gatePoint (geometry)Moment (mathematics)Computer configurationDirectory serviceFunctional (mathematics)Process (computing)Instance (computer science)Product (business)Error messageLibrary (computing)Sheaf (mathematics)Formal verificationDifferent (Kate Ryan album)CodebuchWordFile viewerView (database)State of matterRule of inferenceComputer animation
Vertex (graph theory)Phase transitionLevel (video gaming)BuildingConfiguration spaceSoftware repositoryExecution unitCompilerError messageDemosceneInstance (computer science)Limit (category theory)Projective planeBuildingStandard deviationPhase transitionComputer fileGoodness of fitSoftware repositoryDirectory serviceLevel (video gaming)RootSoftware testingSheaf (mathematics)Product (business)MereologyFormal verificationFunctional (mathematics)Source codeCodeConfiguration spaceTablet computerSubsetDot productIntegrated development environmentElectric generatorState of matterLogic gateError messageExecution unitPower (physics)Statement (computer science)XML
Royal NavyBranch (computer science)Phase transitionConfiguration spaceComputer fileNetwork topologyPoint (geometry)DemosceneFunction (mathematics)BitInstallation artSource codeMultiplication signRevision controlMathematicsProjective planeExecution unitComputer configurationElectronic mailing listNumberUtility softwareSet (mathematics)Computer animation
DemosceneCompilerServer (computing)Distribution (mathematics)Information securityPhase transitionExecution unitConvex hullConfiguration spaceGroup actionPhase transitionStructural loadMultiplication signDirectory serviceNumberExecution unitPoint (geometry)LoginResultantRepository (publishing)Moment (mathematics)InformationBuildingServer (computing)Integrated development environmentComputer fileKey (cryptography)Software testingState of matterWeb 2.0Computer configurationInformation securityUtility softwareInstallation artCompilation albumPresentation of a groupRootMathematicsHoaxDemosceneXMLComputer animation
Functional (mathematics)Attribute grammarMilitary operationClient (computing)Revision controlIntegrated development environmentSet (mathematics)Default (computer science)Software testingDean numberPhase transitionMenu (computing)Drum memoryExecution unitInsertion lossMaxima and minimaConvex hullMIDIDemosceneHardware-in-the-loop simulationBlock (periodic table)Integrated development environmentOcean currentFormal verificationMultiplication signFunctional (mathematics)Phase transitionWeb 2.0Computer fileExecution unitPoint (geometry)Projective planeError messageConfiguration spaceClient (computing)SubsetFunction (mathematics)Term (mathematics)Message passingSoftware testingServer (computing)Variable (mathematics)BuildingType theoryLibrary (computing)Directory serviceBitNumberUniform resource locatorOrder (biology)Set (mathematics)RootFigurate numberStandard deviationLimit (category theory)CodeGoodness of fitVideo gameMereologyNP-hardLocal ringReverse engineeringVotingSource codeInstant MessagingWater vaporSource code
1 (number)Different (Kate Ryan album)Multiplication signInstance (computer science)Field (computer science)Film editingPoint (geometry)Execution unitSoftware testingBlock (periodic table)Default (computer science)Revision controlShift operatorDirectory serviceNumberPhase transitionPresentation of a groupBuildingDemosceneData miningIntegrated development environmentProduct (business)Projective planeUniform resource locatorCASE <Informatik>MassSource codeVariety (linguistics)MereologyConfiguration spaceStreaming mediaForm (programming)Attribute grammarLibrary (computing)Wrapper (data mining)Type theoryError messageCodeAreaLatent heatMetadataElectric generatorStandard deviationFrequencyCodebuchAdditionAutomationInclusion mapComputer animation
BuildingOperator (mathematics)Fitness functionAreaEntire functionProcess (computing)Mutual informationConfiguration spaceForcing (mathematics)Formal verificationAutomationNatural numberSoftware developerLevel (video gaming)QuicksortRandomizationScripting languageState of matterDifferent (Kate Ryan album)WritingGastropod shellMedical imagingRoundness (object)DemosceneIntegrated development environmentRepository (publishing)Phase transitionGroup actionForm (programming)Factory (trading post)DivisorComputer filePoint (geometry)Lecture/Conference
JSONXML
Transcript: English(auto-generated)
Howdy welcome again to beyond the cookbook using chef workflow to bring to us delivered any project I'm JP Robinson. I'm a DevOps architect with SAP and s2 I'm sure most of you are here saw Carmen's presentation this morning and
the main takeaway here is that we are a 100% independent subsidiary of SAP that caters exclusively within the federal space for US government entities So How many of you here know what chef workflow is and have used it before
Okay, some of you for any of you that don't it's a continuous integration continuous delivery pipeline It basically is turnkey solution for if you have chef cookbooks and want to deliver them in a CI CD pipeline very easily It's part of chef automate and it actually does Build cook it uses the build cookbooks so that you can deploy things at a standardized and automated way
Using all the syntax you already know with a cookbook in first place But only deploys cookbooks, right? No You can use your build cookbook to do just about anything. So the build cookbook tells workflow how to deploy your code
delivery trucks the standard turns the example When you do chef generate cookbook it by default will start a new project for you with a delivery directory and a build cookbook That just goes through and calls delivery truck to runs various phases as I said before normal chef resources and can do just about anything a normal chef cookbook can so
Most of you have used workflow before are probably familiar with these phases Basically it goes through verify build acceptance union rehearsal and delivered The idea here is also that verify happens before you merge and there's an approval gate for
merging it before it builds the build is where most CI CD pipelines would say you're supposed to build your artifacts and Then it starts out to acceptance where it starts deploying and testing your artifacts
Once you pass acceptance you have another gate to deliver it into your production environment passing through union rehearsal and delivered delivered being ultimately your production environment So we can take those and kind of separate them into three distinct places
pre-merge pre-merge is everything that happens from the moment you submit your pull request and say this is a change that I want to do Post merge is what happens once that code has been approved and merged into your master tree and Then deployment is the phases that are purely for deploying into production
So they deploy they test And that's all they really do the verify phase I'm gonna go through what delivery truck does with it It runs the our spec chef spec unit tests It does a lint check with rubocop or cook style to make sure that your code is good and passing and
No errors there And then it does a final syntax check with knife cookbook test and also checks to make sure that you've updated your version number in the cookbook because delivery works by pinning the various versions within the environments that it delivers to So if you haven't updated your version, there's nothing there to deliver
Then moves on into the build phase Which has the verify stage again it runs all three of those verify stages again post merge to make sure for instance that if you Submitted your change and then somebody else came along and submitted their change
They you don't have any conflicts or anything that breaks the build after that point The quality and security but then delivery truck these are left intentionally bright blank Because the idea here is that you should write your own quality and security tests publish Publishes the code according to the config.json in your delivery directory
With delivery truck there are several options including your local chef server your local supermarket server Or even the global supermarket server or a get repository Once it passes through build it goes to acceptance the idea here being acceptance is your first dev test environment
pins the cookbooks in the appropriate environment It attempts to find anything that has this cookbook assigned to it and Deploys it via push jobs to make sure that you know chef client runs and it gets deployed out within that environment
Smoke and functional stages are also left intentionally blank Again, so you the idea being you should write your own smoke test for each of your projects or your own functional test The truth is this phase these phases get repeated throughout union rehearsal and delivered
They're exactly the same Going through each of them The only difference is that union also runs these for anything that depends on this project so this is useful for instance if you've got a library cookbook or When developing your own build cookbooks if you've got something that has libraries for instance
You can actually tell it that the main project depends on those library projects And it will actually rerun with the new libraries to make sure that everything works So which of these phases is really important? If you're going to write your own build cookbook well which of these phases
Where do I want to start? What do I want to do with them? That's really up to you. You should decide where things should happen within your project If you've got a project for instance that you need to run kitchen before you merge Then you should put that obviously into the verify section
either in unit lint or syntax If you've got projects that should only be published after a major update Then you should probably check in the acceptance phase and fail acceptance to make if you haven't done a major version update or a minor version update if
To make sure that it does not go through to your production environment basically you can also do things for instance if you wanted to say Well, I want to not have any gates whatsoever I want to basically have it so everything goes through as soon as somebody submits it
You could technically do that by putting everything in the verify stage. It's probably a bad practice to do it however Depends on what you're building basically do you need just a standard delivery truck for building your cookbooks? Do you need something with a little more power? Or do you need to build something entirely different your own vehicle?
So some things to keep in mind as you do your own build cookbooks The phases are flexible You can put whatever you want into any phase So for instance if you want to publish in the provision phase you could do that
You just need to keep in mind What happens in the pre-merge versus the post merge, and then what happens in each of those deployment phases? Keeping the phases close to what they're named for the function Will help you later if you come back to your project and go well where where did I put that again? I don't remember
Some of the limits on the build cookbook It's worth keeping in mind the cookbooks for building are run as a non privileged user on your build notes So that means for instance if you need to install packages to do whatever build you're going to do
You're probably going to have to provide that user with elevated privileges to do so sudo DZ do whatever you use If you need to say compile something else entirely as root You're gonna have to provide it with the ability to do so The other thing is that the phases each of those phases each of those sections
runs on different build nodes So if you have ten build nodes you're not likely to end up on the same build node for the next phase and Even if you do each of them is isolated into its own directory on the build node
So you can't depend that the state Immediately after you finish one phase is going to be the state that you enter the next phase with It completely checks out your project again So that it has a clean. It's a clean slate Don't expect it to remember state at all
So building the build cookbook Where should I start? I've got my project. I've got my source code that I want to make a build cookbook for this isn't a chef cookbook I don't want to chef just do a chef generate cookbook. I want to do a chef generate build cookbook
It will actually add a dot delivery directory with a completely empty cookbook It sets out the recipes named for the phases, which is required But each of those phases will be empty it won't include delivery truck automatically But how do I figure out what goes where
same way you would building any automation project Determine what your build steps are Determine what you need to do pre-merge what you need to actually build and package it for deployment And then how you want to actually do that deployment
basically keep these in mind Anything that you want to do before that code is merged into your code base you want to do in the verify stage Anything that you want to do for building your project you probably want to put into the build phase
Acceptance is kind of a test run of the deployment So it's really a deployment phase, but because of that gate there. I've kind of grouped it into post merge The next part of it is the deployment phases. How am I deploying this into production? How am I deploying this into Union?
How do I deploy this into my stage environment rehearsal, and then how do I deploy it ultimately into the production environment? So I'm going to do a demo I've got a demo project build Apache. It just basically builds Apache from the Apache git repo Based on a configuration file that tells it how I want it to build
It packages it for deployment and deploys it to nodes within my demo environment The code for this can be found at my github Which is github.com slash dream night under the build Apache project
So that will be available so What am I doing with it from my from my end? I've got a unit phase that will actually do a test compile To make sure that before it merges it at least compiles if it doesn't compile Obviously, there's no reason for me to merge that in it's not good code
The lint will actually check my configuration file that I set up for any errors and Reject anything that doesn't have a good configuration file Syntax I have actually set it up to skip entirely for right now the reason for that is I couldn't think of anything else to
Run through before I merged it So I just want to show you guys the cookbook here this is what the configuration file looks like and we'll actually go ahead and make a change here to Bump its build number so that we'll build a new version of it
I've got here my required packages, which is just literally a list of the rpms that are required for it to build Because the cookbook goes through and installs those Where to find the Apache source right now, like I said, it's pointed at the main Apache tree You could fork this and point the point it to your own tree
Apr and Apr utils since those are also required to build Apache where they get that source I've also got a option down here to reduce the spam as it's building and basically not output anything from the make if I wanted it to So I'm going to make
I'm going to actually go ahead and remember to branch first So I'm going to create a branch for the demo just like you normally would in your projects I'm going to save my changes for that
I'm also going to come in here and update to skip the unit phase as well and that's just because compiling Apache takes a bit of time and If I do not cut if I do not skip that phase will be sitting here for five minutes. Just watching it compile
so I'm going to go ahead and commit that And tell it to delivery review so it will automatically pop up to the new change and
Would start running through the phases which right now it's only going to do lint
I'm going to go ahead and approve that and let it go on to the build phase while I go over What it's actually doing so as you can see in my unit recipe here I'm basically just including the setup build and perform build
Actions that I have here Setup build actually walks through loads the configuration file installs the required packages and then sets up checking out each of those git repositories for Apache and its required utilities and Then runs the build comps so that it's ready in any state that I can actually start doing the build for it
So set up the autocomp setup Perform build actually walks through cleans up anything that may be there or left over for any reason and Then runs dot slash configure with whatever options. I specified in my configuration file that it read in
It then just runs make So that's the that's how it actually performs the build so come back to the presentation for a moment the build phase
Verify would actually go through and do another compile post merge again to make sure Nothing has changed since the first time we did it Quality and security I've also left those intentionally blank. I don't have any particular quality or security test
I want to run within this demo Publish it does the full build so this is now we're at build number three This time it will actually take the result of that build Package it up and publish it to a web server that I have within my environment See where this has reached at this point within the build phase. It is actually running the publish now
And you can see it here. It's actually running through Spamming out the compile so while it does that So it runs through again this perform build setup
The other thing that it will do now is actually the package build recipe that I've set up Which will pull from a data bag Get some information like I've got an SSH key that it's using to copy the file over and publish it does the full build
installs it to a fake root directory to install the build locally and then just basically does a tar to Tar up that build file and push it out. It will then go and copy it over to the appropriate place on
The deployment node for the repository I said this takes a while has a lot of spam to it
So I'm going to go ahead and move on for What it does in the next phases so again acceptance you get in rehearsal delivered all do the same thing It will actually set an environment variable within the appropriate environment
For here's where on that web server you need to go to find that new build that we just created that new package It will then do as the smoke phase It will deploy the package locally from that package to make sure that the environment variable setting went, okay
That the package actually will extract okay, and it's doing this locally on the build node itself and Then starts that Apache up Does a get request just a HTTP get to the local Apache server?
And then the functional test will actually Go in deploy a node within that environment that is running a cookbook to that will deploy the code for it Deploy the code in a custom configuration and then also the build node will send a get request to that server To check and see if it's operational so just to go over those a little bit in detail
So the smoke test actually comes in goes to the server which
This with server config that it keeps doing is actually set up in a cookbook called delivery sugar If any of you are familiar with that one Delivery sugar has a lot of things that when you're writing your own custom build cookbooks Will actually make your life a lot easier because it will actually provides a good set of
functions for you to work with for working with your actual live chef server as Opposed to just doing things locally on the build node itself So it actually will come in here figure out what the acceptance name is which is also within delivery sugar
And then I'm actually using a helper from delivery truck to Retrieve that environment back from the chef server So that I can work with it later so I've also got my build root here. I'm sorry. This is not the provision phase provision phase
I'm doing the same type of thing here with the Create fetch or create the environment and then here's where I'm actually going through in setting the node Attributes, so I set up the custom Apache
attributes for the URL Where the doc root for that it should be and what build number it actually is on and then it saves that environment So back to the smoke test The smoke test like I said creates the directory for it pulls back the remote file
And then just extracts it and as you can see this is all The same type of code and same resources that you're familiar with from writing your own cookbooks Anything that you're already automating? You can do in here the same type of way it then starts Apache locally with a appropriate environment from libraries
sends an HTTP request again with a standard chef resource and As long as all that's correct shuts down that Apache server very simple thing for it to do here
So The last part of that would be the functional test Does much of the same thing with going in with server config pulls back a data bag? Actually does a node search here same standard way you would do a node search in any of your other recipes Search for whichever terms you want here recipe custom Apache
Chef environment, whatever environment we're currently in for delivery So if that's your acceptance environment everything project gets its own acceptance environment if it's Union, it'll pull back Union as it's a union environment and Then it will find each of those nodes
It will then go and use knife SSH here to reach out to those nodes and just run chef client here Just so you guys can See the full command here All I'm doing is
Executing chef client and going through with my custom with my user to get into that Once it's run chef client once all those nodes have run chef client Then it'll come through and for each of those nodes It'll send a test request to the port that I've specified for it to listen on 8080 here
And just do a simple get request If that passes then the build passes if any of this fails If any of those nodes fail to deploy it for any reason or anything like that Then obviously the CI CD pipeline fails and it stops at that point go back fix your errors
Continue as you would normally. Oh, let's go back and check and see how that build is doing This was still back in the publish phase here Cuz had lots of output for it. This is with actually packaging it up here
creates the tar file Deploys it and then moves on automatically into acceptance Provision and actually well, here's the Ruby block for setting the current environment
You'll notice I didn't say anything about deploy. I'm not actually doing anything in the deploy phase Smoke Actually deploys out with a custom configuration file here so you can see
See it create the file create the remote file Extract it create the config file for it to use locally And then send the get request up to localhost Then in the functional test
It's just basically running through Sends it off to knife SSH There isn't a whole lot of output from that but completes so that point I can do the say I can basically say deliver it and it's going to go through and Repeat those same phases for each of the environments
That's basically all there is to it. You're just using Whatever chef resources you already know To tell it here's how I want you to build Make configure very simple to do Any other thing else that you have to do you can easily do it through here
Just keeping in mind that runs on the build node and has some limits Any questions for me at this point Mm-hmm that is a hard set order and actually what it does is it runs all three of those phases at the same time
For unit sent went and syntax those three phases all run at the same time. They're all launched at the same time If any of them fail you obviously can't move on from verify when it runs it in the build phase It also will launch all three of those
Verify phases again at the same time before it moves on to quality or publish or anything else But once it moves on from that each of those phases is executed one by one If you have cookbooks that depend on each other
Even if they're not library type cookbooks, like you've got a wrapper cookbook that depends on another cookbook You're essentially using it as a library in that case, even though it's not a chef library
So in that case you would want the wrapper cookbook to run with The attributes you're setting so that when you push it into union rehearsal delivered, you're not just testing Okay, this cookbook with the default attributes works Make sense. Yeah, go ahead the within the dot delivery config where you're defining the build cookbook
You can pull that from here you can pull that I believe you can pull that from the supermarket as well It can be pulled from a variety of sources Worst case scenario you can just specify a git slash slash URL for it. Anybody else have any other questions?
I'm sorry. How many build nodes? Pipelines for this pipeline. This is just a demo. So it's only running the one pipeline
In my production environment We have something like a hundred projects in there. Some of them have more than one pipeline for Instance we separate out say our dev environment pipeline from our QA pipeline. So we have Quite a few. Let me see here. Let me go back in time here if I can
So the question was how do I determine what caused a what caused part of it to fail basically?
So, let me come back to one of my older ones
Here's one that failed for instance on the smoke test when I was writing it originally I Was up late writing it and for some reason thought I needed to put the whole thing into a Ruby block
Which obviously did not work so well When it fails, it's just like a chef run failing And it will give you a trace back and it will tell you Here's where I failed and why I failed so you can see it was processing this Ruby block that I had set up
Undefined method directory for chef resource Ruby block because obviously that's a chef resource and not a Ruby command And it will tell you where It was actually failing. So it outputs, you know, Ruby block smoke test Here's in the cookbook where I need to look at what it failed and why it failed
Just like you would for any of your chef runs that fail If you ever if you use this to say set up a cookbook delivery, which is the example If you forget to bump that metadata It'll very quickly fail out on the syntax check and it will tell you explicitly been the error that it raises
You didn't bump the version number You can do that with your own phases as well Where if it fails you can you know, especially if it's in a Ruby block for instance You can raise your own error message or log your own error message on certain failures
So that's just like you would in the chef run Any other questions Yeah, I have one so I'm very new to chef automate and I noticed that on the pipeline you have for each step You have you you have a recipe for that Did you specify that in the default recipe in the cookbook or did you or what did chef automate automatically pick that up?
Which recipe are you asking about? So in your cookbook and your chef and your in your built cookbook you are you have you have a default recipe does that? Include all the other recipes to go down the pipeline or just shut automate automatic automatically pick that up. This is my default recipe As you can see it's fairly blank
You notice that each of the phases here within the build cookbook And this is set up automatically when you do a chef generate build cookbook Each of these phases are named for what the phase actually is for instance functional When it runs functional it runs the functional recipe when it runs unit it runs the unit recipe
The only place I'm doing includes here are for things like the unit recipe where I'm actually including my to My own custom recipes because I divided the build into set up build and perform build and package build I'm actually including those recipes and if I didn't the only thing that would get run here is whatever's in unit
Or whatever's in the next phase smoke publish etc I'm really new to this, but I'm trying to understand how much of this these kinds of Build cookbooks are publicly available. I mean how much how much do you typically have to have to tweet to get it running?
Okay, that depends on what you're doing if you are doing purely cookbooks Then delivery truck is publicly available as you can see I have it pulled up here. I referenced it a few times
Delivery truck is basically the standard chef workflow Cookbook it used to be called chef delivery if you guys see my shirt and
Delivery truck was basically the standard pipeline for move your cookbook through This will deliver cookbooks into environments. It will pin them for you. It makes it very easy to Take this is my cookbook, and I want to deliver it into a production environment have it pinned
So I'm not worried about Well did I update a version or not which version am I actually pulling it will actually take care of that for you For writing other things that's part of why I'm doing this presentation is to show number one that yes Workflow is very much able to handle whatever you want to throw at it. You do have to write some code for it
Like I said mine is available on my github at github slash dream night You Can take that and modify it as you wish to you know Support whatever kind of build you're doing especially if it's a follows the auto conf configure make make install type of
build If you have something more complex you may have to go ahead and write your own complete code for it If you guys are doing projects I'd encourage you to do similar to like with the supermarket Put your code out there for build cookbooks
Let it be out there because we can all point at different build cookbooks for different things But if you've got say open source projects that you guys are working on and writing a cookbook to compile it and deploy it Put it out there I've got a question regarding the kind of the early pipeline with the developers. I'm on the operation side
And the developers we have they push all their artifacts into Artifactory And so when they go from snapshot to release can that that release push into artifactory can that trigger? The chef automate piece and actually start into that verification to go out into the the deployment phases
Basically right now the review on delivery is kicked off by that CLI command delivery review Delivery review will actually take whatever the current state of the git repository is and
Push it up to delivery Workflow push it up to workflow and then that start kicks off the pipeline at the verify stage Yeah, so now that you've worked this, you know, obviously more than a lot of us Does this feel like a natural fit a good idea for building Apache or building?
VM images or building random thing Using sort of more traditional tools or is this a natural fit or force fit in other words? I think it's a natural fit Partly because I came into things from a very much chef background where I'm writing a lot of cookbooks and things of that nature
If you already have your tools in place You have your tools in place a this can replace them But I can understand that trying to get people to change their ways Even trying to get people to adjust to say using chef Can be kind of a pain Everybody's kind of pulled those teeth at some point. I'm sure
But it is a natural fit if you're writing cookbooks already To go ahead and write a build cookbook and use that as your pipeline To me it makes more sense than using other things where I have to worry about managing say shell scripts or managing You know various different kinds of config files, I already know chef I can use it very naturally
By that same token as far as a natural fit for your build process Like I think this can build just about anything you want it to Yesterday at the partner day. There was actually a demonstration of using it. They're using it to build out an entire demo environment
Build AMI's with packer and then deploy them with an AWS, so it's a very powerful tool Do you have any maybe experience or know of anybody that's making any build cookbooks with terraform I?
Do not know for terraform I don't use terraform specifically I use chef provisioning so I'm a little weak in that area Maybe if anybody here has any experience with that if you could come find me that would be awesome. Okay cool. Thanks
Okay, let's give a really big round of applause for John Paul. Thank you so much