Skip to content

Latest commit

 

History

History
271 lines (178 loc) · 9.19 KB

README.md

File metadata and controls

271 lines (178 loc) · 9.19 KB

Ibeji Containers

This document covers how to containerize the services provided in this repository.

Dockerfile Selection

In-Vehicle Digital Twin Service

To containerize the In-Vehicle Digital Twin Service use one of the following dockerfiles:

Sample Applications

To containerize one of the Ibeji Sample Applications use one of the following dockerfiles:

Configuration Defaults

In-Vehicle Digital Twin Service

This repository provides default configuration files for the In-Vehicle Digital Twin Service running in Standalone and Integrated modes.

Note: Integrated mode runs the In-Vehicle Digital Twin Service with the Chariott Service and the Agemo Service. Other combinations may require config changes.

Sample Applications

For the samples, this repository provides default configuration files for the Property Provider and Property Consumer samples.

Note: Other samples may need config changes (see Running the Samples for config changes).

Docker Containers

Prerequisites

Install Docker

Running in Docker

To run the service in a Docker container:

Note: Before running any of the following commands, replace all placeholders (wrapped with <>).

  1. Run the following command in the project root directory to build the docker container from the Dockerfile:

    docker build -t <image_name> -f <Dockerfile> [--build-arg=APP_NAME=<project name>] [--build-arg=FEATURES="<module name(s)>"] .

    Note: The FEATURES build arg only applies to the dockerfiles for In-Vehicle Digital Twin Service.

    For example, to build an image for the invehicle-digital-twin project in Standalone mode:

    docker build -t invehicle_digital_twin -f Dockerfile.amd64 .

    Or to build an image for the invehicle-digital-twin project with the Managed Subscribe module:

    docker build -t invehicle_digital_twin -f Dockerfile.amd64 --build-arg=FEATURES="managed_subscribe" .

    Note: Modules for Ibeji are enabled via the --features flag. The FEATURES build arg passes one or more features to the cargo build argument. If you want to add multiple features, add each feature followed by a space e.g. "module_1 module_2".

    Or to build an image for the property-provider sample for aarch64:

    docker build -t property_provider -f ./samples/Dockerfile.samples.arm64 --build-arg=APP_NAME=property-provider .

    Note: The build arg APP_NAME needs to be passed in for all sample applications to build the correct sample.

  2. Once the container has been built, start the container in interactive mode with the following command in the project root directory:

    docker run --name <container_name> --network=host -it --rm <image_name>

    Note: Most images built will require configuration overrides. See Running in Docker with overridden configuration for more details.

    For example, to run the invehicle_digital_twin standalone image built in step 1:

    docker run --name invehicle_digital_twin --network=host -it --rm invehicle_digital_twin

    Note: A custom network is recommended when using a container for anything but testing.

  3. To detach from the container, enter:

    Ctrl + p, Ctrl + q

  4. To stop the container, enter:

    docker stop <container_name>

    For example, to stop the invehicle_digital_twin container started in step 2:

    docker stop invehicle_digital_twin

Running in Docker with overridden configuration

Follow the steps in Running in Docker to build the container.

  1. To run the container with overridden configuration, create your config file and set an environment variable called CONFIG_HOME to the path to the config file:

    export CONFIG_HOME={path to directory containing config file}

    For example, to set the configuration for the Property Provider sample, run:

    export CONFIG_HOME={path-to-repo-root}/samples/container/config/provider

    Note: See Configuration Defaults for more information. If running a sample other than the Property sample you will need to create your own configuration files.

  2. Then run the container with the following command:

    docker run -v ${CONFIG_HOME}:/mnt/config --name <container_name> --network=host -it --rm <image_name>

    For example, to run the property_provider image with overridden configuration:

    docker run -v ${CONFIG_HOME}:/mnt/config --name property_provider --network=host -it --rm property_provider

Podman

Prerequisites

Install Podman

Running in Podman

To run the service in a Podman container:

Note: Before running any of the following commands, replace all placeholders (wrapped with <>).

  1. Run the following command in the project root directory to build the podman container from the Dockerfile:

    podman build -t <image_name> -f <Dockerfile> [--build-arg=APP_NAME=<project name>] [--build-arg=FEATURES="<module name(s)>"] .

    Note: The FEATURES build arg only applies to the dockerfiles for In-Vehicle Digital Twin Service.

    For example, to build an image for the invehicle-digital-twin project in Standalone mode:

    podman build -t invehicle_digital_twin -f Dockerfile.amd64 .

    Or to build an image for the invehicle-digital-twin project with the Managed Subscribe module:

    podman build -t invehicle_digital_twin -f Dockerfile.amd64 --build-arg=FEATURES="managed_subscribe" .

    Note: Modules for Ibeji are enabled via the --features flag. The FEATURES build arg passes one or more features to the cargo build argument. If you want to add multiple features, add each feature followed by a space e.g. "module_1 module_2".

    Or to build an image for the property-provider sample for aarch64:

    podman build -t property_provider -f ./samples/Dockerfile.samples.arm64 --build-arg=APP_NAME=property-provider .

    Note: The build arg APP_NAME needs to be passed in for all sample applications to build the correct sample.

  2. Once the container has been built, start the container with the following command in the project root directory:

    podman run --network=host <image_name>

    Note: Most images built will require configuration overrides. See Running in Podman with overridden configuration for more details.

    For example, to run the invehicle_digital_twin image built in step 1:

    podman run --network=host invehicle_digital_twin

    Note: A custom network is recommended when using a container for anything but testing.

  3. To stop the container, run:

    podman ps -f ancestor=<image_name> --format="{{.Names}}" | xargs podman stop

    For example, to stop the invehicle_digital_twin container started in step 2:

    podman ps -f ancestor=localhost/invehicle_digital_twin:latest --format="{{.Names}}" | xargs podman stop

Running in Podman with overridden configuration

Follow the steps in Running in Podman to build the container.

  1. To run the container with overridden configuration, create your config file and set an environment variable called CONFIG_HOME to the path to the config file:

    export CONFIG_HOME={path to directory containing config file}

    For example, to set the configuration for the Property Provider sample, run:

    export CONFIG_HOME={path-to-repo-root}/samples/container/config/provider

    Note: See Configuration Defaults for more information. If running a sample other than the Property sample you will need to create your own configuration files.

  2. Then run the container with the following command:

    podman run --mount=type=bind,src=${CONFIG_HOME},dst=/mnt/config,ro=true --network=host <image_name>

    For example, to run the property_provider image with overridden configuration:

    podman run --mount=type=bind,src=${CONFIG_HOME},dst=/mnt/config,ro=true --network=host property_provider