Allow container restart.

Previously, an already-existent 'clr-sdk' container could not be restarted
because the 'setup.py' ENTRYPOINT script would error out attempting to
create the 'clr' user again.

This patch adds new exception handling specifically for this case, ignoring
these errors. Any other error encountered creating the 'clr' user and group
is still considered a critical failure.

With this, an existent container can be restarted with 'docker start -i <id>'.

This patch also makes minor corrections and clarification to the README.

Signed-off-by: Kevin C. Wells <kevin.c.wells@intel.com>
This commit is contained in:
Kevin C. Wells
2018-08-28 13:16:41 -05:00
committed by Simental Magana, Marcos
parent 3ef1b98fff
commit f908a1d8d7
2 changed files with 42 additions and 19 deletions
+33 -19
View File
@@ -1,13 +1,13 @@
# Clear SDK Container
[![](https://images.microbadger.com/badges/image/clearlinux/clr-sdk.svg)](http://microbadger.com/images/clearlinux/clr-sdk "Get your own image badge on microbadger.com")
[![](https://images.microbadger.com/badges/version/clearlinux/clr-sdk.svg)](http://microbadger.com/images/clearlinux/clr-sdk "Get your own version badge on microbadger.com")
[![](https://images.microbadger.com/badges/image/clearlinux/clr-sdk.svg)](https://microbadger.com/images/clearlinux/clr-sdk "Get your own image badge on microbadger.com")
[![](https://images.microbadger.com/badges/version/clearlinux/clr-sdk.svg)](https://microbadger.com/images/clearlinux/clr-sdk "Get your own version badge on microbadger.com")
This repo provides a Clear Linux* SDK container for running the Clear Linux devloper tools. This container will allow you to use the [mixer tool](https://clearlinux.org/features/mixer) on your Linux host.
> ### :warning: **IMPORTANT NOTE:**
> As of `mixer` version `5.0.0`, you **must** run mixer with the `--native` flag
> inside the `clr-sdk` container. This is because `mixer` now attempts to
> automatically run build commands within a docker container containing the
> As of `mixer` version `5.0.0`, you **must** run `mixer` with the `--native`
> flag inside the `clr-sdk` container. This is because `mixer` now attempts to
> automatically run build commands within a Docker container containing the
> correct toolchain version for the mix you are building. This is not possible
> if you are already running within the `clr-sdk` container. The `--native` flag
> foregoes this container launch, allowing the build to proceed as normal.
@@ -15,9 +15,11 @@ This repo provides a Clear Linux* SDK container for running the Clear Linux devl
> If you _need_ this containerized `mixer` behavior to build across formats, it
> is possible to mount the host system's Docker socket when you launch the
> container (i.e., passing `-v /var/run/docker.sock:/var/run/docker.sock` to
> your `docker run`). This has the effect of the in-container docker actually
> your `docker run`). This has the effect of the in-container Docker actually
> spawning _sibling_ containers on the host system, rather than _child_
> containers within the `clr-sdk` container.
> containers within the `clr-sdk` container. In this case, the workdir path
> _inside_ the container must match the path on the host, as it is the host's
> Docker daemon that will be interpreting the path.
# Build
## Building Locally
@@ -26,7 +28,11 @@ This repo provides a Clear Linux* SDK container for running the Clear Linux devl
docker build -t clearlinux/clr-sdk .
```
> #### Note:
> If you are behind a firewall, you may need to pass the `--network host` and/or `--build-arg http://<proxy>:<port>` flags to docker build to configure your proxy.
> If you are behind a firewall, you may need to pass the `--network host`,
> `--build-arg http_proxy=http://<proxy>:<port>`,
> `--build-arg https_proxy=https://<proxy>:<port>`, and/or
> `--build-arg no_proxy=http://<proxy>:<port>`, flags to `docker build` to
> configure your proxy.
#### Optional Build ARGs
* `--build-arg swupd_args` specifies [SWUPD](https://clearlinux.org/documentation/swupdate_how_to_run_the_updater.html) flags passed to the update during build.
@@ -46,15 +52,15 @@ docker pull clearlinux/clr-sdk
directory is what determines the user id used inside the container. If you
are not the owner of the directory, you may not have access to the files the
container creates.
* **Running the docker container**
* **Running the Docker container**
Assuming you created the mix directory as described above, the command to
run the docker container would be:
Assuming you created the mix directory as described above, the command t
o run the Docker container would be:
```
docker run --rm -it -v /home/myuser/mix:/home/clr/mix clearlinux/clr-sdk --mixdir=/home/clr/mix
```
### A note on the arguments:
#### docker run arguments
#### `docker run` arguments
* `--rm` cleans up and removes the container once you exit it. The files
generated in the mounted directory will persist on the host.
* `-it` attaches an interactive terminal.
@@ -65,17 +71,25 @@ docker pull clearlinux/clr-sdk
generated within the container if it doesn't already exist, and will
replace whatever may already be there, so _use caution_.
* If you plan to run `sudo mixer build image` inside the container, you
must additionally pass `--privileged -v /dev:/dev` to docker run. This is
because `mixer build-image` needs to mount a loopback device for generating
must additionally pass `--privileged -v /dev:/dev` to `docker run`. This is
because `mixer build image` needs to mount a loopback device for generating
the image filesystem. The `-v /dev:/dev` bind mount is due to an [outstanding
issue](https://github.com/moby/moby/issues/27886) where loopback devices
created within the container are not visible within the container. **This
can have serious side effects**, so only run the container in this way for
this specific command.
created within the container are not visible within the container.
> ### :warning: **IMPORTANT NOTE:**
> Running the container in this way can have **serious side effects** on
> your host machine, so only use these flags for this specific command. **Do
> not run the container this way as your regular work flow.**
>
> * `--privileged` permits the container to create the loopback device, but
> also removes other security limitations normally placed on containers.
> * `-v /dev:/dev` permits the container to see the loopback device, but
> also gives the container direct access to the _host's_ entire device
> directory, including all mounted drives.
* If you are behind a firewall, you may need to pass the `--network host`
flag to docker run, and then set your `http_proxy` and `https_proxy`
flag to `docker run`, and then set your `http_proxy` and `https_proxy`
environment variables within the container to configure your proxy.
* Please see note above about mounting the host system's docker socket if
* Please see note above about mounting the host system's Docker socket if
you cannot use the `--native` flag when running `mixer`.
#### Container arguments
* `-d`|`--mixdir` tells the startup script what directory you mounted using
+9
View File
@@ -60,6 +60,15 @@ try:
cmd = "useradd -Nmo -g {} -G mock,wheelnopw -u {} {}".format(gid,uid,user)
subprocess.run(cmd.split(),stdout=subprocess.PIPE,stderr=subprocess.STDOUT,check=True)
os.chown("/home/{}".format(user),uid,gid)
except subprocess.CalledProcessError as e:
if e.returncode and e.returncode == 9:
# Both 'groupadd' and 'useradd' return error code 9 if the group/user
# already exists. This will happen if the container is restarted or
# this script is manually re-run.
pass
else:
sys.stderr.write("Error creating user.\n")
sys.exit(1)
except subprocess.SubprocessError:
sys.stderr.write("Error creating user.\n")
sys.exit(1)