You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 30, 2020. It is now read-only.
Copy file name to clipboardExpand all lines: Documentation/unit-files-and-scheduling.md
+35-5
Original file line number
Diff line number
Diff line change
@@ -59,6 +59,35 @@ To use instance units, simply create a unit file whose name matches the `<name>@
59
59
60
60
When working with instance units, it is strongly recommended that all units be _entirely homogenous_. This means that any unit created as, say, `[email protected]`, should be created only from the unit named `[email protected]`. This homogeneity will be enforced by the fleet API in future.
61
61
62
+
## Definition of the Install Section
63
+
64
+
Unit files which have an `[Install]` section will be automatically enabled by fleet. This means that the states of such unit files cannot be tracked by fleet. For example, assume we have loaded this `my.service` unit file:
65
+
66
+
```ini
67
+
[Service]
68
+
ExecStart=/bin/bash -c "while true; do echo my.service unit file; sleep 1; done"
69
+
```
70
+
71
+
and then loaded an additional [sidekick][sidekick] discovery unit `my_discovery.service`:
72
+
73
+
```ini
74
+
[Unit]
75
+
BindsTo=my.service
76
+
77
+
[Service]
78
+
ExecStart=/bin/bash -c "while true; do echo my_discovery.service unit file; sleep 1; done"
79
+
80
+
[Install]
81
+
WantedBy=my.service
82
+
83
+
[X-Fleet]
84
+
MachineOf=my.service
85
+
```
86
+
87
+
fleet will load and enable the `my_discovery.service` unit above because it contains an `[Install]` section. When `my.service` is started, systemd will also start `my_discovery.service`, independent of the desired state defined for `my_discovery.service` in fleet. This can cause confusion between the output of `fleetctl list-units` and `systemctl list-units`, which will not match in this scenario. Use `fleetctl status my_discovery.service` to explicitly identify the service and get its actual unit status.
88
+
89
+
If systemd can not enable the unit which has `[Install]` section, fleet will interrupt load process and return an error.
90
+
62
91
## systemd specifiers
63
92
64
93
When evaluating the `[X-Fleet]` section, fleet supports a subset of systemd's [specifiers][systemd specifiers] to perform variable substitution. The following specifiers are currently supported:
@@ -90,7 +119,7 @@ For more details on the specific behavior of the engine, read more about [fleet'
90
119
91
120
For non-global units, several different directives are available to control the engine's scheduling decision.
92
121
93
-
#####Schedule unit to specific machine
122
+
## Schedule unit to specific machine
94
123
95
124
The `MachineID` option of a unit file causes the system to schedule a unit to a machine identified by the option's value.
96
125
@@ -100,7 +129,7 @@ One must use the entire ID when setting `MachineID` - the shortened ID returned
100
129
fleet depends on its host to generate an identifier at `/etc/machine-id`, which is handled today by systemd.
101
130
Read more about machine IDs in the [official systemd documentation][machine-id].
102
131
103
-
#####Schedule unit to machine with specific metadata
132
+
## Schedule unit to machine with specific metadata
104
133
105
134
The `MachineMetadata` option of a unit file allows you to set conditional metadata required for a machine to be elegible.
106
135
@@ -183,7 +212,7 @@ app.service fd1d3e94.../10.0.0.1 active running
183
212
A machine is not automatically configured with metadata.
184
213
A deployer may define machine metadata using the `metadata`[config option][config-option].
185
214
186
-
#####Schedule unit next to another unit
215
+
## Schedule unit next to another unit
187
216
188
217
In order for a unit to be scheduled to the same machine as another unit, a unit file can define `MachineOf`.
189
218
The value of this option is the exact name of another unit in the system, which we'll call the target unit.
@@ -195,13 +224,13 @@ Follower units will reschedule themselves around the cluster to ensure their `Ma
195
224
196
225
Note that currently `MachineOf`_cannot_ be a bidirectional dependency: i.e., if unit `foo.service` has `MachineOf=bar.service`, then `bar.service` must not have a `MachineOf=foo.service`, or fleet will be unable to schedule the units.
197
226
198
-
#####Schedule unit away from other unit(s)
227
+
## Schedule unit away from other unit(s)
199
228
200
229
The value of the `Conflicts` option is a [glob pattern][glob-pattern] defining which other units next to which a given unit must not be scheduled. A unit may have multiple `Conflicts` options.
201
230
202
231
If a unit is scheduled to the system without an `Conflicts` option, other units' conflicts still take effect and prevent the new unit from being scheduled to machines where conflicts exist.
203
232
204
-
#####Dynamic requirements
233
+
## Dynamic requirements
205
234
206
235
fleet supports several [systemd specifiers][systemd-specifiers] to allow requirements to be dynamically determined based on a Unit's name. This means that the same unit can be used for multiple Units and the requirements are dynamically substituted when the Unit is scheduled.
207
236
@@ -223,4 +252,5 @@ would result in an effective `MachineOf` of `foo.socket`. Using the same unit sn
0 commit comments