While agents are one part of the system running as processes alongside the Varnish process they are also a modeling
concept. An agent is where a VCL is deployed. An agent is also tagged with one or more tags. The tags are then used
by deployments
to tell the system where to deploy a specific set of VCL files.
An agent can have the following states:
Each agent must have a unique name that is specified during the startup of the agent process. For agents that use different private token (version 5.0+), the name can be the same as long as different tokens are used for the agents.
Agents becomes Locked
when brainz reports wrong unique ID (UID) to them. The brainz UID is created the first time brainz initializes
the database. When agents are started for the first time, brainz will provide them with this UID. The agents will then only
accept deploy/undeploy/reloads from a brainz instance that uses the same UID.
This functionality is to prevent undeploys if the database becomes reset or destroyed without backups. Starting brainz with a new database, without any data, would otherwise undeploy all VCLs from all agents. This is because the database is empty and brainz will perform deployments based on what is in the database, in this case nothing. So in order to avoid this scenario, the agents that had previous deployments, will become locked.
Locked agents will keep running the previously known VCLs until unlocked.
Before unlocking an agent make sure that the database contains the same settings that should be deployed to the agents. That means, same tags, deployments,
domains, vclgroups and that the agents have the same tags as before. Once this is added to the database (via API/UI/CLI) the agents UID file can be removed.
The UID file exists in the agents configured base-dir
and is called agent.uid
. Remove the file and then restart the agent and the agent will become
running again. Brainz will then update the agent with correct deployments. If the deployments are the same as before, no undeploys will be made.
However, if the VCLGroup IDs has changed compared to before the database reset, the VCLs will be re-deployed. This will however not remove any cached content and existing sessions will be kept until ended on the previous VCL configuration in Varnish.