|
Answer» Chef Client run COULD be performed in the following modes: - Local mode: In this mode, we can run the Chef Client against the local Chef repository mimicking the behaviour as if it was running against a Chef Server. This is achieved through ‘Chef zero’ (previously a standalone tool)which acts as a lightweight Chef Server. Running in local mode is the easiest way to quickly test and VERIFY the infrastructure code, though this has some disadvantages of not testing the authentication or SECURITY checks which are needed when we connect to the actual Chef Server
- Why run mode: Why run mode gives you a preview of what will happen on your node when you perform Chef Client run. In why run mode no actual modifications are done on your node. This mode follows the principle of no-op(no operation). All actions that happen in normal Chef Client run is performed until the actual configuration of the node.
- Run in FIPS (Federal Information Processing Standards) mode: Chef Client run can be performed in FIPS mode to follow the FIPS standards. Any violation of these standards will throw a run exception.
- Run as a service/daemon: In this mode, we can make the Chef Client run happen in our desired time intervals. Chef Infra Client cookbook from GitHub repository is used to perform Chef Client run.
- Run with elevated privileges: When we are trying to configure nodes with DIFFERENT OS like Windows or LINUX we often run into some errors while performing Chef Client run, this is mostly due to the access privileges on these systems. The client run solves this issue by providing the ability to run the Chef Client with root access rather than by a local system user
- Run as a non-root user: This mode is helpful when multiple teams (devs, administration, etc) are involved in your infrastructure development and not everyone needs the same amount of accesses. You can limit the access and make the Chef Client run as a non-root user.
|
