- Closes#1318.
- Closes#1378.
- Reduces the complexity and coupling for IP allocation.
- Runtimes connect to networks for the life of the running container.
The runtime shuts down on connection loss.
- Networks automatically deallocate a runtime's IP address and hostname
record on connection loss.
- Removes AllocatedAttachment as this is no longer necessary. The
`bootstrap()` XPC now takes a `NetworkBootstrapInfo` array which
parallels the attachments in the bundle config and provides the network
plugin attributes needed to create VM network interface configurations.
## Type of Change
- [x] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Motivation and Context
Simplify IP allocation and make deallocation more reliable.
## Testing
- [x] Tested locally
- [ ] Added/updated tests
- [ ] Added/updated docs
- Closes#1433.
- Renames `env` parameter to `dynamicEnv` to differentiate these
special-case environment variables from the standard container
environment.
- Use `[String: String]` instead of `[String: String]?`.
- Default to `[:]` when an down-revision client calls bootstrap without
supplying `dynamicEnv`.
This PR fixes#357, passing `SSH_AUTH_SOCK` env variable from current
terminal to the `SandboxService` so that the container can mount the
correct ssh auth socket. For that, it introduces `env` parameters to
`bootstrap` RPC of both `ContainersService` and `SandboxService`. This
parameter is used only for passing `SSH_AUTH_SOCK` now, but can be
extended to pass more runtime env variables.
This PR is a follow up PR of #1214.
## Type of Change
- [X] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Motivation and Context
Container run `--ssh` was inheriting `SSH_AUTH_SOCK` env variable from
launchd, not from current terminal.
## Testing
- [X] Tested locally
- [ ] Added/updated tests
- [ ] Added/updated docs
`container stop` has an option `-t` for `Seconds to wait before killing
the containers` (see
[here](https://github.com/apple/container/blob/ce7736105747f48debb37ca1999b562b4bfae23c/Sources/ContainerCommands/Container/ContainerStop.swift#L39)).
This timeout is used to determine when the SandboxService should stop
waiting for the container to gracefully exit with `SIGTERM` (or another
provided signal) and send `SIGKILL`.
Today, we were setting the `SandboxService.stop` XPC call's timeout to
the value provided to `container stop -t` plus 1 second. This is
problematic in cases where the code flow to send SIGKILL to the
container then forcefully stop the VM does not complete within one
second of the SIGTERM timeout being hit. In those cases, we will return
that the XPC stop call failed due to hitting the timeout. In some cases
this may happen even though the container and VM have both been
successfully stopped.
This PR removes that XPC timeout for `SandboxService.stop` entirely. We
cannot reliably determine in the SandboxClient, which may be used by
third party runtime plugins to support additional container runtimes,
how long it may take for SIGKILL to kill the container and stop related
resources.
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
- Closes#1206.
- Closes#1185.
- Closes#507.
- Addresses existing log messages for #642.
- Nondeterministic CI errors are resulting from very slow launch times
for the first runtime helper, which causes ContainersService to be
locked for longer than our 20 sec timeout. Bumping the timeout to 60
seconds addresses this case for now.
- Since many log messages needed to be changed to troubleshoot the
issue, updated all log messages to use structured logging, and
implemented consistent entry/exit logging for all service operations.
- Added logging for ContainerService lock acquisition to help with
finding root cause for the slow service startup.
- Plumbed the `--debug` flag on both `container system start` and
`container system logs` so that the flag is actually useful.
- Updated the `install-init.sh` script so that can install in a custom
app root directory.
## Type of Change
- [x] New feature
- [x] Breaking change
## Motivation and Context
We want to be able to support using multiple network plugins during
`container`'s lifetime. This additionally means needing to pick an
interface strategy to interpret a network attachment based on what
network plugin was used to create that attachment. This PR will
potentially replace https://github.com/apple/container/pull/1081.
Followups:
- doc updates to include the ability to specify plugin in the network
creation cli
## Testing
- [x] Tested locally
- [x] Added/updated tests
- Closes#461.
- Extract core types into ContainerResources target.
- Extract ContainerNetworkServiceClient from ContainerNetworkService.
- Relocate sandbox client from ContainerClient to
ContainerSandboxServiceClient.
- Relocate ContainerClient to ContainerAPIServiceClient.
- Common structure from services and clients under Source/Services.
Updated project hierarchy:
```
Sources/CAuditToken - audit token access wrapper
Sources/CLI - CLI executable
Sources/ContainerBuild - builder
Sources/ContainerCommands - CLI command implementations
Sources/ContainerLog - logging helpers
Sources/ContainerPersistence - persistent data and system property helpers
Sources/ContainerPlugin - plugin system
Sources/ContainerResource - resource (container, image, volume, network) types
Sources/ContainerVersion - version helpers
Sources/ContainerXPC - XPC helpers
Sources/CVersion - injected project version
Sources/DNSServer - container DNS resolver
Sources/Helpers - service executables
Sources/Services/*/Client - service clients
Sources/Services/*/Server - service implementations
Sources/SocketForwarder - port forwarding
Sources/TerminalProgress - progress bar
```
## Type of Change
- [ ] Bug fix
- [ ] New feature
- [x] Breaking change
- [ ] Documentation update
## Motivation and Context
The ContainerClient library was a bit of a grab bag. This refactor
applies a more sensible project and library structure for resource data
types, services, and clients.
## Testing
- [x] Tested locally
- [x] Added/updated tests
- [ ] Added/updated docs
J Logan