----
Watch: Chef Workflow
// Chef Blog
On March 9th, I presented a live webinar on the Chef Workflow – a set of tools and a series of well-defined steps that support the DevOps principles of automation, collaboration and transparency. With the Chef workflow, you can progress from local development to collaboration across teams. You can identify a problem, correct it in local development, then, through a series of automated gates, prove not just that your code works in isolation, but also in conjunction with its dependencies, even when they're produced by other teams. We call it the Chef workflow because we provide all the components you need to deploy applications and infrastructure with speed and control.
Watch the recording below to see me demonstrate the Chef workflow. At the end of the recording, you'll know how to take control of your entire deployment pipeline, and understand how the Chef workflow supports DevOps principles. At the end of this post, I've included some Q&A from the presentation.
Is Chef Delivery open source?
Chef Delivery is a part of a paid premium subscription. The delivery-cli package and delivery-truck (build cookbook) of Delivery is open source.
For organizations whos environments are physically separated, how would Delivery work for them? i.e. if your union, rehearsal and production environments have no communication between them.
Chef Delivery publishes artifacts (in the Publish stage) to a Chef Server. Chef Delivery would need to be able to access your Chef Servers.
Does this workflow assume that you keep track of databags and node definitions in git?
In the webinar, we demonstrated a cookbook workflow. You can create build-cookbooks that allow you to track databags and node definitions as pipelines in Chef Delivery.
Does the Chef Workflow include two different pipeline processes, one from developer code change to the Union phase, and another from Union phase to the Delivery phase?
The Chef Workflow can have 1 to many Acceptance pipelines, where changes can move at their own cadence. Once those changes are Delivered, the changes move thru a single unified pipeine, one change at a time thru a series of stages called Union, Rehearsal and Delivered.
As we can see there is approval button. In Production to get approvals do we have any notify system integrated in Chef to notify respective higher authorities or do we have to do it manually ?
In the current release of Chef Delivery, Slack integration is currently supported to notify a Slack channel when there are changes to be approved and changes to be deilvered. Future enhancements to this feature can be expected based on customer feedback and roadmap prioritization.
Are you storing each cookbook on a separate repository? How does the build stage work on that context?
Part of the Chef Workflow prescribes that you have a 1 cookbook per repo structure. Remember, once we Approve the change, the Chef Workflow says that we should merge the change back to master so as to not have long running feature branches. Since the merge operation is a change, we need to re-test for Unit, Lint and Syntax, and we do that as the first 3 phases of the Build stage, we then test for quality and/or security (which are defined in your project's build cookbook), before being published to the Chef server in the publish stage.
How are you tying in your CI tools into the Verify stage?
The Chef Workflow stresses testing all throughout a change that occurs. When we first submit a change, we are immediately running a set of tests. Once these tests pass, a quality gate in the form of the Approve stage begins, where someone can review the change for best practices within their organization. When the change is approved, we then merge the change back to master (Continuous Integration). We discussed the Chef workflow being a collaborative workflow and tooling; here we are providing the tooling that enforces CI by merging back to master.
Can we see a file that actually describes a compliance rule?
Here is an example of Chef Compliance profile that describes os-hardening rules https://supermarket.chef.io/tools/os-hardening.
Does this mean we need to move our existing CI to Chef Delivery?
This does not mean that you need to move your existing CI to Chef Delivery. Part of the Chef Workflow allows for flexibility in a versionable artifact called a build-cookbook. In this cookbook, you can call existing jobs that exist in your CI tool as you see fit to provide a complementary solution for your requirements.
Can you give some concreate examples of what different things get tested in Union/Rehersal and Delivered?
The same tests that are run in Acceptance (smoke, functional) are also run in Union, Rehearsal and Delivered. The key difference is that when the change makes it to Union, the change is tested with the depdendencies for that project. In Rehearsal, the tests are run again to ensure that if Union breaks, once you remediate the break in Union, that your changes also pass.
Can you make more than 1 change against multiple servers or a group of server?
In the Chef Workflow, we see peope acting on code, and that code then acting on systems, The Chef Workflow provides a set of tools and a collaborative workflow to allow you to make changes and at velocity. In the demonstration, we showed a change being made to a cookbook and that change being brought from local dev all the way out to being Deilvered. There was only one node that had its runlist configured for that cookbook, but I could have had many nodes configured with that runlist, which would have had the change I made applied once the change competed the Deilvered stage.
In your demo, you commited the change locally but did not push changes to remote repository/branch. So does the the 'delivery' command commit your changes to remote branch before running your tests?
That is correct. Remember that i created a feature branch for my changse and then ultimately pushed those changes using delivery review. Had I not created that feature branch, I would not have been able to commit that change to Chef Delivery.
Is there anything to prevent dev from committing code to master manually?
Yes. Part of the Chef Worklow says you should not commit changes directly to master, and we enforce this workflow with the tooling.
Which CI tools are you integrated with?
Chef Delivery is a fully featured CI/CD toolchain that also prescribes a collaborative workflow, with the pipeline being a versionable artifact (the buid-cookbook). Within the build-cookbook, you have the ability to call jobs to other CI tools as you see fit.
What language or DSL are the tests written in that get run in the Union and Rehearsal environments? Are they Chef Audit controls (written in ServerSpec or InSpec)?
For the webinar, the tests were written in ServerSpec and executed in chef-client's audit mode, but as of this Q&A, we have released InSpec support in the Chef Workflow, where you can run InSpec as part of your pipeline.
What's the syntax test, is it not part of lint tool testing?
In the Chef Workflow, Lint checks execute foodcritic. For Syntax testing, we are ensuring that there are no syntactical issues in a cookbook that would prevent it from being published to a Chef Server.
Is this a kind of integrating Jenkins into Chef as Chef workflow?
The Chef workflow (and specifically Chef Delivery) provides a versionable artifact for your pipelines called a build-cookbook. In this build-cookbook, you can define what you want run in the different stages. As such, you can call a job you might already have configured in Jenkins and ensure that job completes before your change moves forward.
What git solutions does Chef Delivery work with? github? gitlab?
Currently, Chef Delivery supports integration with Stash, Github, Github Enterprise and BitBucket.
Can you clarify the difference between the Verify and Build phases of the pipeline process? Both seem to run lint, syntax, and unit test on the same commit of the code. Is the idea that the Review phase might introduce further changes, so the Build phases repeat those verification steps?
When a change is submitted, we run automated tests as part of the Verify stage. When that change is approved, as part of the Chef Workflow, we merge the change back into the master branch of that project. This is done as we want to ensure that we do not have long running feature branches where regressions and merge conflicts can be introduced. Since we are also making a change to the project (merging back to master), the Chef Workflow tells us that we need to test again, so we execute the Lint, Syntax and Unit tests again.
Does Chef Compliance basically run chef-client in audit-only mode on nodes? If so, how does it know which recipes (audit controls) to run on each node?
Chef Compliance actually runs a remote scan on the nodes, so there is no chef-client actually running when Chef Compliance scans a node.
What does the "Smoke" do?
"Smoke" is a phase that is run in your Acceptance, Union, Rehearsal and Delivered Stages. For the project that you are working with in Chef Delivery, you would define what a smoke test is for your project. In the example in the webinar, smoke would be used to test if the website was returning a 200 code, or if the port was responding on the correct port.
How much does Chef Delivery cost without the premium subscription?
Pricing for Chef products can be found at https://www.chef.io/pricing/. For Chef Delivery without a premium subscription, please contact sales@chef.io.
----
Shared via my feedly reader
Sent from my iPad
No comments:
Post a Comment