What's changed: Initial version
6.4EEM and orchestration
Teaches reading applets of EEM (Embedded Event Manager)—which runs autonomously on the device—as pairs of event (what triggers it: a syslog pattern, a timer, or a CLI command) and action (what it runs), so you can automate configuration, troubleshooting, and data collection. It also contrasts external configuration management as agent-based (Puppet/Chef, a resident agent pulling) versus agentless (Ansible, pushing over SSH).
Automation comes in two families—what runs entirely inside the device and what governs devices from outside—and ENCOR covers both. The flagship of the former is EEM, whose defining trait is that the device itself holds a rule saying "when this event occurs, run this," operating with no external server or human in the loop. It shines exactly where a human cannot stand by, such as capturing information about a fault that flares for a moment at 3 a.m. and vanishes. The latter family is configuration management, where the design fork you are tested on is whether or not an agent resides on the target. Neither is merely a "handy tool"; treat both as choices driven by requirements—does it need autonomy, large-scale standardization, or is installing software on the device even possible?
6.4.1EEM applets: pairs of event and action
Continue reading — free sign-up
You're reading the free preview. Sign up free to read this section in full, plus every chapter (including 4+) and all questions.