Jenkins and Chef: Infrastructure CI and Automated Deployment

Visits: 707

Remember for your interview and even more important to keep that job!

Jenkins does infrastructure as code

Chef  as well as puppet do configuration management

Git is a Source Code Management (SCM) system not software configuration management system

https://github.com/gchq/BoilingFrogs/issues/5

So you need all 3

  1. Manage your code updates, even scripts in Github. Git remember every change to every line, so you can figure where you got it right, or God forbid where you brought on the white screen of browser death
  2. Chef manages which version and build you are installing
  3. Jenkins manages the infrastructure, its nice web interface is more fun than YAML and Json but still you’ll need such things.

I hope I got it right!

Leave your comments in the disquss form below

Also

https://acloud.guru/forums/aws-certified-solutions-architect-professional/discussion/-KBj_DMm6GktFGtCQhJa/opsworks-vs-cloudformation

OpsWorks is an orchestration tool like Chef – in fact, it’s derived from Chef – Puppet, Ansible or Saltstalk. You use Opsworks to specify the state that you want your network to be in by specifying the state that you want each resource – server instances, applications, storage – that you want that resource to be in. And you specify the state that you want each resource to be in by specifying the value that you want for each attribute of the state. For example, you might want the apache service to be always and up running and top always start on bootup with apache as the user and apache as the Linux group.

CloudFormation is a json template that specifies the state of the resource(s) that you want to deploy i.e. you want to deploy an AWS EC2 micro t2 instance in us-east-1 as part of VPC 192.168.1.0/24. In the case of an EC2 instance, you can specify what should run on that resource through your custom bash script in the user-data section of the EC2 resource. CloudFormation is just a template. The template gets fleshed out as a running resource only if you run it either through the AWS Management Console for CloudFormation or if you run the aws cli command for Cloudformation i.e. aws cloudformation

ElasticBeanstalk is a PAAS- you can upload the specifically Ruby/Rails, node.js or Python/django or Python/Flask apps. If you’re running anything else like Scala, Haskell or anything else, create a Docker image for it and upload that Docker image into Elastic Beanstalk (*).You can do the uploading of your app into Elastic Beanstalk by either running the aws cli for CloudFormation or you create a recipe for Opsworks to upload your app into Elastic Beanstalk. You can also run the aws cli for Cloudformation through Opsworks.

I think of it CF vs OW as a bit like level 1 and level 2. CF is like Terraform, its is fully coded automation of almost every service in AWS. So use if you have a very extensive service that requires full description of environments or templated stacks to cover low level services like auto scaling, spot instance, redshift, Cloudwatch alarmss and much more. The configuration time is much more extensive, and time consuming.

OW is basically AWS managed Chef. It has some great features for automation via the GUI, and you can configure most things. The great thing about Opsworks is that a good Devops can script the system, so someone that has little knowledge of infrastructure or cloud can still deploy apps super simply, and in very little time. However it is not as powerful as CF

So i think of it as CFT for large environments / many users and OpsWorks for smaller solutions or Application/Solution Stacks

Leave a Reply