engine: lease model • a lease model to enforce that only one engine is running at a time • every time a reconciliation is due, an engine will attempt to take a lease on etcd engine
Reconciliation • reconcile the actual state with the desired state • reconciliation loop • triggered periodically • triggered by certain events from etcd current state desired state
Cluster-level Unit State • inactive: known by fleet, but not assigned to a machine • loaded: assigned to a machine and loaded into systemd there, but not started • launched: loaded into systemd, and fleet has called the equivalent of systemctl start inactive loaded launched (unknown)
systemd-level Unit State • ACTIVE: the high-level unit activation state, i.e. generalization of SUB • SUB: the low-level unit activation state, values depend on unit type
Unit Section • Used to define generic information about a unit • Options that are common for all unit-types are generally placed here [Unit] Description=foo service # Requirements Requires=bar.service # Dependency ordering After=bar.service
Service Section • Used to set directives that are specific to service units • Most of the unit-types above have associated sections for unit- type-specific information • See man page: [Service] TimeoutStartSec=0 # Pre-start and Start ExecStartPre=-/usr/bin/docker kill foo ExecStartPre=-/usr/bin/docker rm foo ExecStart=/usr/bin/docker run —name foo -p 80:80 username/foo # Stop ExecStop=/usr/bin/docker stop foo http://www.freedesktop.org/software/systemd/man/systemd.unit.html
X-Fleet Section • Used to set scheduling requirements for the unit for use with fleet • Using this section, you can require that certain conditions be true in order for a unit to be scheduled on a host [X-Fleet] Conflicts=foo.*.service MachineMetadata=location=tokyo
Global units registry • Global units are not scheduled through the engine • Non-global units are scheduled by the engine Non-global units engine Global / Non-global units
Global / Non-global units • Non-global units are scheduled by the engine • Global units are not scheduled through the engine (A global unit is one with Global=true in its X-Fleet section, fleet agents still check the MachineMetadata option before starting them. Other options are ignored.)
Control the engine's scheduling decision • Schedule unit to specific machine • Schedule unit to machine with specific metadata • Schedule unit next to another unit • Schedule unit away from other unit(s)
Schedule unit to machine with specific metadata registry Non-global units engine metadata=“region=us-west" [X-Fleet] MachineMetadata="region=us-west-1"
Schedule unit away from other unit(s) registry Non-global units engine [email protected] [X-Fleet] Conflicts=hello@*.service Conflicts! [email protected] Conflicts! The value of the Conflicts option is a glob pattern defining
agent_ttl • An Agent will be considered dead if it exceeds this amount of time to communicate with the Registry • The agent will attempt a heartbeat at half of this value agent heartbeat agent is alive? I’m alive registry
INI-formatted Config File # Lower the logging threshold. Acceptable values are 0, 1, and 2. A higher # value corresponds to a lower logging threshold. verbosity=0 # An Agent will be considered dead if it exceeds this amount of time to # communicate with the Registry. The agent will attempt a heartbeat at half # of this value. agent_ttl="36s" • fleet will look at for this config file by default • The flag may be passed the location to the fleetd binary /etc/fleet/fleet.conf —config
Environment Variables # Enable debug logging by setting “verbosity” option to 1 $ FLEET_VERBOSITY=1 /usr/bin/fleetd # Increase “agent_ttl” to default 36s from 30s (default) $ FLEET_AGENT_TTL=36s /usr/bin/fleetd • Options provided in an environment variable will override the corresponding option provided in a config file • simply prefix the name of a given option with 'FLEET_', while uppercasing the rest of the name
Configure via cloud-config #cloud-config coreos: fleet: verbosity: 1 agent-ttl: 36s public-ip: $public_ipv4 metadata: region=us-west • The coreos.fleet.* parameters allow for the configuration of fleet through environment variables.
Entities • Units • Unit systems-level States • Machines The fleet API allows you to manage the state of the cluster using JSON over HTTP /units /state /machines https://github.com/coreos/fleet/blob/master/Documentation/api-v1.md
Unit Entity • This simply declares what should be happening; the backend system still has to react to the changes in this desired state (cluster-level) fleetd desire state (cluster-level state) current state (cluster-level state) /units /units
Unit Entity • If you would like to get the systemd-level state, communicate with UnitState entities desire state (cluster-level state) current state (system-level state) /units /state fleetd