Hi, I'm brand new to this and may be doing something unordinary here. I've gone through and created a chef server with a chef client on it. I was figuring I'd just do my development work right on the server. I've done this using the instructions at:
When I get to page three, which is the page I linked above, it tells me to run the bootstrap command. Is there a way to have it not SSH since it's local? Thanks!
Hopefully you're using Chef Client 14 and Chef Server 12, the latest versions. If you've got the package already installed you can use "chef-client" with the -s option for the Chef server (https://localhost I guess) and --validation_key KEY_FILE for registering as a new client. That said, I don't think that's a great idea since you're ideally using Chef to manage your Chef server, if you can't talk to the Chef server you can't run the Chef client to manage the Chef server. Perhaps use "chef-client -z" or using an external Chef server to manage your Chef server (perhaps https://manage.chef.io).
Hmmm, hadn't thought of that. Do you have a link that discusses using your chef client to manage your chef server. I was just building the server out from that page above manually. So then I would house it's own server recipes and such ON it. Does that start me all over or do I just create the recipe based on what I've already done?
If you want to use Chef to manage your Chef Server, the key is to limit human interaction with the Chef Server. Keep everything in source control and use CI/CD to automate pushing out changes to your servers.
Thanks,
Matt Ray
Regional Manager, Customer Architect - APJ :: Chef matt@chef.io
Hmmf. If you have to manage one of your hosts entirely manually, especially for things like package management or security credentials, why are you bothering to use a configuration automation tool like Chef? Why not just write your own scripts for everything?
Part of the answer is that Chef has good cookbooks for doing well defined actions. Part of the risk is that you'll cut your own legs out from under yourself with firewall changes, or erroneous bootstrapping, and kill the Chef server you need to use to reset the chef server itself. One way around that is don't rely on the Chef service on that particular host. Use chef-zero, instead, with the git repository you should be using anyway to upload cookbooks and roles and databags. I've maintained a git repo for just that sort of use for years, at https://github.com/nkadel/nkadel-chef-local-wrapper .It's also very useful for testing chef cookbooks or roles in an environment with no communication with the chef server, such as on an isolated VM in a de-militarized zone of your local network.
That is a greate way to test out chef-server roles and playbooks if you need it, without corrupting cookbooks that live servers use. Enjoy.
With the customer I'm working with, they have 1 master Chef Server managed with chef-solo since it doesn't have internet access to use manage.chef.io. They have 20 datacenters each have a chef-client managed Chef Server and only have network access to the master Chef Server and Automate. There are no manually managed machines, except for a few internal services that existed before Chef was brought in that will slowly be incorporated (AD, Artifactory, secrets management) and those will get InSpec profiles at least.
In the past I have used a chef server in each DC. then mirrored the hosts and client info via jenkins job. Of course the jenkins job also handled all commits to databags etc. The plus with this approach is that you get benefits of HA without the added cost and higher throughput, and if you put a lb in front of your chef servers, like an F5 for example you can take advantage of GLB and HA.
The cookbooks are great but may not meet 100% of your needs. So be sure to use a wrapper cookbook.