Don't Depend on a Single Chef Server Divide and conquer...
summary
Argues for replacing one monolithic Chef server with a federated model for Chef Automate on AWS: teams run their own Chef Automates to reduce blast radius while a central security team pushes compliance via a repo of profiles. Demonstrates an enforcement pipeline using AWS CodePipeline + CodeBuild that does tests then knife upload of profiles so nodes with the opsworks audit cookbook automatically pick up audits. Scales to tens of thousands of nodes.
AI-written summary · about
chapters (8)
- 0:00Start
- 7:12Alternatives to To Run a Federated Server
- 9:21Network Connectivity
- 10:56Single Point of Failure
- 11:34Scalability and Load
- 13:58How To Enforce Company Write Policies
- 21:02Audit Code Book
- 39:48How Many Nodes Can a Single Chev Automate Server Managed by Opsworks Handle
related talks
38mAn Approach to Air-Gapped Deployment
09mWorking with Serverless Functions and CI/CD
28mA tale of Ansible fanboy
41mChef Cookbook Testing Like a Pro
30mContinuous Integration and Delivery for serverless apps
47mRobust CI/CD Pipelines for Serverless Applications
39m/Automate. Serverless and event-driven approach to DevOps
29mHow is the role of DevOps changing in a Serverless environment?