{"id":21186683,"url":"https://github.com/geontech/docker-redhawk-minimal","last_synced_at":"2025-07-11T09:35:10.942Z","repository":{"id":146038829,"uuid":"92838863","full_name":"Geontech/docker-redhawk-minimal","owner":"Geontech","description":"Docker -based minimal installation of REDHAWK SDR to facilitate Docker-based Component execution","archived":false,"fork":false,"pushed_at":"2017-05-30T14:01:47.000Z","size":24,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-07-02T19:53:05.150Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"lgpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Geontech.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-05-30T14:00:57.000Z","updated_at":"2017-05-30T14:01:48.000Z","dependencies_parsed_at":null,"dependency_job_id":"ff1886d5-db95-4d3a-b658-6ac9e8b5146c","html_url":"https://github.com/Geontech/docker-redhawk-minimal","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/Geontech/docker-redhawk-minimal","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Geontech%2Fdocker-redhawk-minimal","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Geontech%2Fdocker-redhawk-minimal/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Geontech%2Fdocker-redhawk-minimal/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Geontech%2Fdocker-redhawk-minimal/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Geontech","download_url":"https://codeload.github.com/Geontech/docker-redhawk-minimal/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Geontech%2Fdocker-redhawk-minimal/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":264777820,"owners_count":23662555,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-20T18:25:12.979Z","updated_at":"2025-07-11T09:35:10.663Z","avatar_url":"https://github.com/Geontech.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Docker REDHAWK Minimal\n\nThis project creates a minimal installation of REDHAWK SDR in an Ubuntu 16.04 Docker Image with an external volume for SDRROOT.  The external volume facilitates adding and removing Components without modifying the base image.  The overarching purpose of these is to facilitate having an external, modified GPP execute Components within the resulting Docker Container ([found here](https://github.com/GeonTech/core-framework)).  This allows the Component to interface with other installed frameworks, etc., within that image.\n\n\u003e Note: It is up to the integrator to extend the minimal image with their own additional dependencies, etc., for their intended integration.  This image is only REDHAWK SDR, no GPP.\n\n## Component Requirements\n\nThe following are two new properties for REDHAWK Components that will be launchable with the modified GPP:\n\n|ID|Required|Description|\n|---|---|---|\n| `__DOCKER_IMAGE__` | YES | Specifies the Docker image name, e.g., `my_image:tag`.|\n| `__DOCKER_ARGS__` | NO | Allows for additional arguments to be passed on the command line to Docker, e.g., `--volumes-from my-filesystem -v something:/else` |\n\n\u003e Note: These IDs look a little strange compared to typical property IDs.  The `__DOCKER_IMAGE__` ID was chosen for a potential familiarity since it exists in the Application Factory implementation source code (but no where else) in the core-framework.  The `__DOCKER_ARGS__` was therefore chosen for no other reason but to look similar to `__DOCKER_IMAGE__`.  \n\n## Host Domain Requirements\n\nThe host REDHAWK Domain must be running Docker and have the [modified](https://github.com/GeonTech/core-framework) GPP installed in place of the standard REDHAWK one.  It's a fork, so its base capabilities are the same as the standard one.  It has been extended to recognize the above property IDs and prefix a string of docker arguments ahead of the standard Component executable arguments.  \n\nThe result is the GPP will launch and manage a Docker container of the Component rather than locally launching the Component.  All CORBA connections, etc., will be handled automatically via REDHAWK, leaving the Component designer to manage their own needs.  The full command issued by the GPP becomes:\n\n    docker run --sig-proxy=true --rm --net=host \\\n        --name COMPONENT_ID_COLON_IS_HYPHEN \\\n        -v docker_omniorb_cfg:/etc/omniORB.cfg \\\n        __DOCKER_ARGS__ \\\n        __DOCKER_IMAGE__ \\\n        ./component/NAME/IMPL/EXEC \\\n        OTHER_TYPICAL_REDHAWK_ARGUMENTS\n\nThe `docker_omniorb_cfg` property on the GPP allows you to configure the OmniORB instance within the launched containers to use a different IP than local host for the OmniORB connection.\n\n\u003e **Security Note:** By default, it is set to `/etc/omniORB.cfg`, so you may wish to change this property for security reasons.  It should be set to the absolute path in your file system.\n\n## Setup\n\nThe following integration was performed on CentOS 7 64-bit.  \n\n    make\n\nThe build process will run through several images to establish the `redhawk/minimal` image and `redhawk-sdrroot-fs` volume.  Effort has been taken to ensure that build dependencies of REDHAWK are handled in a separate image to avoid inflating the image size unnecessarily.\n\n### Build Process Explained\n\nThe build process will generate the `redhawk/run-deps` runtime dependencies based off Ubuntu 16.04.  It then creates the `redhawk/build-deps` image which adds in development libraries, headers, etc. and source code for XSD 3.3.0, OmniEvents 2.7, and REDHAWK SDR 2.0.4.  Then the `redhawk/build` image is created to inject the build scripts (internal and external).  \n\nAt this point the external `builder/run-builder.sh` script runs the `redhawk/build` image and outputs the OmniEvents and REDHAWK products into the host OS.  Next, these two products are copied into the `redhawk/minimal` folder so that the `redhawk/minimal` image can be built, which uses the ADD command to pull those products into this new base image.  Finally, the `redhawk-sdrroot-fs` and `redhawk-ossiehome-fs` volumes are created, making the installation area of REDHAWK external to the image (in this case, `/opt/redhawk/sdr`).\n\n### Proof of Life: REDHAWK\n\n#### Very Basic\n\nThe first option is to use `make test` to run a container of `redhawk/minimal` with the SDRROOT mounted.  From there, you can run `nodeBooter -D` to see the default domain start.\n\n#### Get the Popcorn\n\nAnother option is to manually boot the new `redhawk/minimal` image as a Domain in the host OS, if we have another system running Omni services (and prefereably, REDHAWK).  \n\nCreate an omniORB.cfg file that references that system's IP address and ensure ports are not blocked.  Then start a container of the image:\n\n    docker run -it --rm --net=host \\\n        -v PATH_TO_YOUR_OMNIORB_CFG/omniORB.cfg:/etc/omniORB.cfg \\\n        --volumes-from redhawk-sdrroot-fs \\\n        redhawk/minimal \\\n        /bin/bash -l -c \"nodeBooter -D --domainname REDHAWK_DOCKER\"\n\nUsing the REDHAWK IDE, Explorer, or the Python interface on the host OS, you should be able to see a new domain: `REDHAWK_DOCKER`.\n\n    \u003e\u003e\u003e from ossie.utils import redhawk\n    \u003e\u003e\u003e redhawk.scan()\n    ['REDHAWK_DOCKER']\n\nLike any other REDHAWK Domain, you can have Device Managers join this Domain.\n\nPress `CTRL+C` to quit the container and shut down this domain.\n\n## Installing a New Component\n\nThere are two environment variables for using the `component-installer` make target.\n\n| Name | Required | Description | Default |\n| --- | --- | --- | --- |\n| `RH_COMPONENT` | YES | The absolute path to the REDHAWK Component to install | NONE |\n| `BASE_IMAGE` | NO | End user Docker image that inherits from `redhawk/component-installer` or provides its `WORKDIR`, `CMD`, and `install.sh` script | `redhawk/component-installer` |\n\nThe Component also needs to support the (presently) standard `./build.sh` script style where `distclean` fully cleans the project directory, and `./build.sh` builds all known implementations.  \n\nFor example, to perform the installation of the DockerComponent:\n\n    make component-installer \\\n        RH_COMPONENT=${PWD}/example/DockerComponent\n\n## Using a Component in a Waveform\n\nOne of the main reasons we went to this trouble is to have a Component with dependencies that are not available in the host OS (or are difficult to have, etc.).  This likely means being unable to compile the Component in the host OS.  The good news is you don't need to be able to compile it to use the Component in a Waveform.\n\nTo use a Component in a Waveform, copy the Component into the host system's `$SDRROOT/dom/components` folder.  In essence you're installing it _without compiling it_.  And since you don't need an executable in the host system, touch the file name for the implementation(s):\n\n    cp -r SomeCppComponent $SDRROOT/dom/components\n    cd $SDRROOT/dom/components/SomeCppComponent/cpp\n    touch SomeCppComponent\n\nThis will let you reference the Component in a Waveform in the IDE and permit you to launch the Waveform even though the executable is invalid (in the host system).\n\n\u003e Note: For Python Components, there is no need to touch a file since the script is the executable.\n\n## Next Steps\n\nTake a moment to look in the `component-installer` directory.  Looking at the `run-install.sh`, you'll notice it runs the associated `redhawk/component-installer` image.  The Dockerfile for that image relies on the `redhawk/build-deps` image and mounts the already-built `redhawk-ossiehome-fs` and `redhawk-sdrroot-fs`.  This comprises a build environment suitable for compiling and installing REDHAWK Components (and other assets).  The runtime image (`redhawk/minimal`) only requires SDRROOT to be mounted unless OSSIEHOME has been modified by some other source.\n\nEfforts to extend this build process, to insert new runtime and build dependencies, should inherit from the `redhawk/run-deps` and `redhawk/build-deps` images, respectively.  For the latter, any installation process requiring the OSSIEHOME or SDRROOT locations should also mount those volumes (e.g., `--volumes-from redhawk-ossiehome-fs`).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgeontech%2Fdocker-redhawk-minimal","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgeontech%2Fdocker-redhawk-minimal","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgeontech%2Fdocker-redhawk-minimal/lists"}