Hello folks,
I’m new to Chef and to configuration management (and never wrote code on regular basis) - I’ve installed Chef 12 server on CentOS 7 and setup my windows workstation per the instructions.
My question is regarding the management of my chef repo - I uploaded it to the server using knife upload, what’s next? I do I download it and make sure to continue from where I stopped?
One more question - where the server can I see my uploads?
Thanks!
Such a huge topic… but here goes.
First welcome to the world of the chef ecosystem! I say ecosystem specifically so you from the start understand that chef alone and chef server alone are only the essential core parts of your future workflow but they will not be the only things you do!
to answer your immediate question knife coobook list will list your uploaded cookbooks… knife cookbook list -a the -a will list ALL versions of the cookbooks (important to know for adding constraints)
Here’s some topics that I wish i knew ‘sooner’ rather than later when I first dived into chef.
- chefDK - (https://downloads.chef.io/chef-dk/) - a chef development kit that attempts to make everyone’s workstation at least match versions of the software used
- berkshelf - (http://berkshelf.com/) - dropping the idea of chef-repo’s cookbooks folders… and instead using 1 git repository for each cookbook (good video / old but really still applicable / berkshelf way https://www.youtube.com/watch?v=hYt0E84kYUI ) berkshelf is primarily for DEPENDENCY management but following its workflow will yield some good results… it also provides a way to upload cookbooks instead of using knife upload (use berkshelf from start you’ll be better off sooner)
- test kitchen - ( http://kitchen.ci/ ) a testing platform for chef… can use integration “drivers” which are basically where to provision test machines to (vagrant/virtualbox/ec2 etc etc) I would start with virtualbox/vagrant building local machines ( some of this is mostly done for you and defined in a YAML configuration - kitchen.yml - then you can test your cookbooks with it and add integration tests
- serverspec - ( http://serverspec.org/resource_types.html ) a testing framework for servers… this is something test kitchen can easily leverage… if you follow the link you can see examples of things you can test… anything from file ownership to contents of a file …etc… so if chef puts /opt/something/here you can verify its doing so with serverspec and integrate it into things like jenkins for CI purposes / promotion etc
- chef-server - the chef server specially for ‘private hosted’ like you have is basically a somewhat ‘dumb’ server that houses your nodes information (like CPU/memory/cookbooks/runlists/ etc) and acts as the repository of your cookbooks (which you can use berkshelf to push to the server instead of knife)
- knife - well knife is always used but you will find its more for changing values or outputting things / modifying some node data or environments
- environments - this is my opinion - but i treat environments as an application stack… not the traditional dv/qa/prod type… instead … think the e-commerce infrastructure in USA… vs the e-commerce infrastructure in China… and those become environments ecomm-usa ecomm-china etc… if you treat it this way you get a lot of flexibility in setting many ‘environmental’ settings… such as the mail server relay host for china vs usa… this will make more and more sense as you dive into things like attributes
- attributes - ( https://docs.chef.io/attributes.html ) attributes can be used in many ways from defining a hostname that can be overwritten to just about any tweakable value you can think of that you would add your business knowledge to and apply as it works for you - whether its setting a web server port or the name of a user folder… think of attributes as a value that can be set in different ways… though you must embrace it within your code and handle it properly… read the link to get some basic information about the ‘precedence’ as it is very critical to know! all in all … embrace it early on and avoid coding ANYTHING in chef ‘statically’ … think of an installation path for an app - using an attribute you can set that dynamically as needed instead of directory ‘/my/app’ you could use directory node[‘mycookbook’][‘my_app_path’]
- cookbook versions - yes this matters a lot… typically chef uses the ‘latest’ version by default of a cookbook… but lets say you need a controlled rollout… lets say again ecommerce-usa needs 1.2.3 of myapp cookbook… but ecommerce-china is not scheduled to be updated just yet… you can keep it on 1.2.2 by using ‘version constraints’ in the environment for example to keep them at that version until you’re ready
- chef is ruby! - use ruby as much as you can to extend basic needs of chef… from just making better decisions for you or doing more complex calculations or conditions in general for your cookbook
- knife.rb - its also ruby you can get pretty fancy sometimes
- Berksfile - for once you understand berkshelf more… Berksfile acts as a definition of where to resolve cookbooks … think of it kind of like DNS for cookbooks in a way… it kind of just tells you where to get cookbooks… or resolving naming issues (2 cookbooks with same name? how does one resolve it - well berkfile can do this. Also Berksfile is ruby - it can do complex things too…
- Use a good editor - i recommend sublime text 3 with the chef helper - check this video for a quick demo on the chef module for sublime text 3 (https://www.youtube.com/watch?v=4VtDj_ar1Xg)
- WINDOWS specific - i urge you STRONGLY coming from someone who first tackled chef from a windows machine… to get a linux VM on your windows machine and use THAT to do your most of your work… though because of the nature of virtualization if you chose to use vagrant/test kitchen together you will still have to ‘build’ your testing machines (kitchen converge is the command) from windows prompts… but just setup a share between windows / linux and you will be so much happier
- Vagrant - use it for local testing… get the same OS as you use for your target (test kitchen with vagrant can support building multiple machines so you can test your code against rhel/ubuntu/centos all in one go from one code base
- EC2 - if you have the $$ you can just dive into doing your test kitchen testing on ec2
sorry these is just a brain dump! but hope somehow some of this stuff helps out…
I know from the start some of the things make almost no sense… but just try and digest all the things in small chunks and understand that working SUCCESSFULLY with chef is about understanding all the chef ecosystem… not chef alone…
hope it helps
Just to note it's been "superseded" by inspec doing the same and adding compliance scans also.
Thank you both! going to do some homework and come back with some questions… 
Here is the first question - you guys didn’t mention Spork, is it a recommended tool? Should I use Berkshelf over Spork?
I’m trying to find the easiest way to manage our repo with little to no knowledge on code version management.
I never used it - I’ve seen it before but don’t truly agree with the direction it wants for a workflow. I feel like you will kind of flow into your own ‘workflow’ and just choosing one solution that may not fit your needs is ill advised. Try it out though if you want.
btw, when I run berks init i get the following message:
DEPRECATED: This command is being deprecated in favor of chef generate cookbook and will soon return an error.
Please use chef generate cookbook instead of this command.
Doesn’t really align with everything i read about repo management…
Honestly - i don’t work for chef or know their ideas or plans… but i would just go with what works and keep an eye out incase of things like that… it’s just letting you know that chef internal tools are trying to do the same thing… (sometimes differently than the solution that was depcracated)
it shouldn’t impact you much right now to get going… and when you have your head wrapped around it better you can decide what direction to go in then
Thanks for the clarification…
It is really overwhelming and confusing for me as a Chef newbie to have so many options…
indeed… go with the things we said before though… focus on them… practice on those… and then see where the current (and ever changing current status of things is) and adapt etc… its a never ending learning experience to understand the chef ecosystem