Clean up typos in docs, fix reference to default subnet (#71)

This commit is contained in:
owenarthur
2025-06-09 17:40:27 -07:00
committed by GitHub
parent 9868562b5a
commit f1e9f0143c
5 changed files with 16 additions and 16 deletions
+5 -5
View File
@@ -13,7 +13,7 @@ Build `container` and the background services from source, and run basic and int
make all test integration
```
Copy the binaries to `/usr/local/bin` and `/usr/local/libexec` (requires entering the an administrator password):
Copy the binaries to `/usr/local/bin` and `/usr/local/libexec` (requires entering an administrator password):
```bash
make install
@@ -36,19 +36,19 @@ of the `container` repository. Ensure that you [follow containerization instruct
to prepare your build environment.
2. In your development shell, go to the `container` project directory.
```
cd container
```
3. If the `container` services are already running, stop them.
3. If the `container` services are already running, stop them.
```
bin/container system stop
```
4. Configure the environment variable `CONTAINERIZATION_PATH` to refer to your Containerization project, and update your `Package.resolved` file.
```
export CONTAINERIZATION_PATH=../containerization
swift package update containerization
@@ -75,7 +75,7 @@ to prepare your build environment.
To revert to using the Containerization dependency from your `Package.swift`:
1. Unset your `CONTAINERIZATION_PATH` environment variable, and update `Package.resolved`.
```
unset CONTAINERIZATION_PATH
swift package update containerization
+1 -1
View File
@@ -1,7 +1,7 @@
# `container`
`container` is a tool that you can use to create and run Linux containers as lightweight virtual machines on your Mac. It's written in Swift, and optimized for Apple silicon.
`container` is a tool that you can use to create and run Linux containers as lightweight virtual machines on your Mac. It's written in Swift, and optimized for Apple silicon.
The tool consumes and produces OCI-compliant container images, so you can pull and run images from any standard container registry. You can push images that you build to those registries as well, and run the images in any other OCI-compliant application.
+3 -3
View File
@@ -94,7 +94,7 @@ container images push registry.example.com/fido/web-test:latest
Use the `inspect` command and send the result to the `jq` command to get pretty-printed JSON for the images or containers that you specify:
<pre>
% container images inspect web-test | jq
% container images inspect web-test | jq
[
{
"name": "web-test:latest",
@@ -152,9 +152,9 @@ The `container logs` command displays the output from your containerized applica
<pre>
% container run -d --dns-domain test --name my-web-server --rm registry.example.com/fido/web-test:latest
my-web-server
% curl http://my-web-server.test
% curl http://my-web-server.test
&lt;!DOCTYPE html>&lt;html>&lt;head>&lt;title>Hello&lt;/title>&lt;/head>&lt;body>&lt;h1>Hello, world!&lt;/h1>&lt;/body>&lt;/html>
% container logs my-web-server
% container logs my-web-server
192.168.64.1 - - [15/May/2025 03:00:03] "GET / HTTP/1.1" 200 -
%
</pre>
+4 -4
View File
@@ -45,15 +45,15 @@ When `container-apiserver` starts, it launches an XPC helper `container-core-ima
## What limitations does `container` have today?
With the initial release of `container`, you get basic facilities for building and running containers, but many common containerization features remain to be implemented. Consider [contributing](/CONTRIBUTING.md) new features and bug fixes to `container` and the Containerization projects!
With the initial release of `container`, you get basic facilities for building and running containers, but many common containerization features remain to be implemented. Consider [contributing](../CONTRIBUTING.md) new features and bug fixes to `container` and the Containerization projects!
### Container to host networking
In the initial release, there is no way to route traffic directly from a client in a container to an host-based application listening on the loopback interface at 127.0.0.1. If you were to configure the application in your container to connect to 127.0.0.1 or `localhost`, requests would simply go to the loopback interface in the container, rather than your host-based service.
In the initial release, there is no way to route traffic directly from a client in a container to a host-based application listening on the loopback interface at 127.0.0.1. If you were to configure the application in your container to connect to 127.0.0.1 or `localhost`, requests would simply go to the loopback interface in the container, rather than your host-based service.
You can work around this limitation by configuring the host-based application to listen on the wildcard address 0.0.0.0, but this practice is insecure and not recommended because, without firewall rules, this exposes the application to external requests.
A more secure approach uses `socat` to redirect traffic from the container network gateway to the host-based service. For example, to forward traffic for port 8000, configure your containerized application to connect to `192.68.64.1:8000` instead of `127.0.0.1:8000`, and then run the following command in a terminal on your Mac to forward the port traffic from the gateway to the host:
A more secure approach uses `socat` to redirect traffic from the container network gateway to the host-based service. For example, to forward traffic for port 8000, configure your containerized application to connect to `192.168.64.1:8000` instead of `127.0.0.1:8000`, and then run the following command in a terminal on your Mac to forward the port traffic from the gateway to the host:
```bash
socat TCP-LISTEN:8000,fork,bind=192.168.64.1 TCP:127.0.0.1:8000
@@ -79,7 +79,7 @@ In macOS 15, limitations in the vmnet framework mean that the container network
Normally, vmnet creates the container network using the CIDR address 192.168.64.1/24, and on macOS 15, `container` defaults to using this CIDR address in the network helper. To diagnose and resolve issues stemming from a subnet address mismatch between vmnet and the network helper:
- Before creating the first container, scan the output of the command `ifconfig` for all bridge interface named similarly to `bridge100`.
- Before creating the first container, scan the output of the command `ifconfig` for a bridge interface named similarly to `bridge100`.
- After creating the first container, run `ifconfig` again, and locate the new bridge interface to determine container the subnet address.
- Run `container ls` to check the IP address given to the container by the network helper. If the address corresponds to a different network:
- Run `container system stop` to terminate the services for `container`.
+3 -3
View File
@@ -21,7 +21,7 @@ If you have not installed a Linux kernel yet, the command will prompt you to ins
Verifying apiserver is running...
Installing base container filesystem...
No default kernel configured.
No default kernel configured.
Install the recommended default kernel from [https://github.com/kata-containers/kata-containers/releases/download/3.17.0/kata-static-3.17.0-arm64.tar.xz]? [Y/n]: y
Installing kernel...
%
@@ -188,7 +188,7 @@ Open the website, using the container's IP address in the URL:
open http://192.168.64.3
```
If you configured the local domain `test` earlier in the tutorial, you can also open the page the full hostname for the container:
If you configured the local domain `test` earlier in the tutorial, you can also open the page with the full hostname for the container:
```bash
open http://my-web-server.test
@@ -244,7 +244,7 @@ container run -it --rm web-test curl http://my-web-server.test
## Run a published image
Push your image to a container registry, publishing it so that you and others can use it.
Push your image to a container registry, publishing it so that you and others can use it.
### Publish the web server image