{"id":22753675,"url":"https://github.com/slaclab/mohs_docker","last_synced_at":"2026-02-02T16:02:18.829Z","repository":{"id":259288481,"uuid":"876330183","full_name":"slaclab/Mohs_docker","owner":"slaclab","description":null,"archived":false,"fork":false,"pushed_at":"2025-07-23T18:32:54.000Z","size":21,"stargazers_count":2,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-07-23T21:12:32.767Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/slaclab.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"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":"2024-10-21T19:34:39.000Z","updated_at":"2025-07-23T18:32:58.000Z","dependencies_parsed_at":null,"dependency_job_id":"ef2f3e20-46e5-4693-bf4c-c3af41db86c1","html_url":"https://github.com/slaclab/Mohs_docker","commit_stats":null,"previous_names":["madmeuy/mohs_docker","slaclab/mohs_docker"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/slaclab/Mohs_docker","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slaclab%2FMohs_docker","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slaclab%2FMohs_docker/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slaclab%2FMohs_docker/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slaclab%2FMohs_docker/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/slaclab","download_url":"https://codeload.github.com/slaclab/Mohs_docker/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slaclab%2FMohs_docker/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29015091,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-02T14:58:54.169Z","status":"ssl_error","status_checked_at":"2026-02-02T14:58:51.285Z","response_time":58,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"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-12-11T06:12:30.594Z","updated_at":"2026-02-02T16:02:18.795Z","avatar_url":"https://github.com/slaclab.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"from: https://gitlab.lbl.gov/ci-cd/mohs-basic\n\nDocker container based testing\n==============================\n\nRecipes and Docker images to support LBL CI/CD servers.\n\n### Introduction\n\nThe support for doing CI through running tests on a bare machine in a shell\neventually gets painful because of ever changing dependencies and their versions,\nfor this single reason it is better to move to a more abstract system like docker.\n\n#### Advantages\n\n1. If you develop gateware/firmware and need motivation look at\n    this [talk](https://ohwr.org/project/ohr-meta/wikis/uploads/bf22cc74d57b32e19f26df532ad80c02/ci_tests_talk.pdf)\n2. Track dependencies and requirements through Dockerfile\n3. Ease of use with Docker (Industry seems to be running with it, and a lot of\n    work to leverage upon)\n4. Most CI out there is currently being done with docker\n5. When changes are made to Dockerfile, the updated dependencies get installed\n    automatically.\n\n#### Disadvantages\n\n1. Not so lean. Linux images are big, especially, when stuff needs to be\n    installed by hand, and there are no two ways about it.\n2. Managing requires a bit of investment into the docker ecosystem, which isn't\n    small.\n\n### Using Docker in CI/CD\n\nWe are using Docker as the basis of our CI/CD strategy\u003e\n\n#### References\n\n1. [A good introduction to Docker](https://docs.docker.com/engine/docker-overview/)\n2. There seem to be obvious\n    [pitfalls in terms of security](https://docs.docker.com/engine/security/security/#docker-daemon-attack-surface)\n\n#### Key takeaways\n\nWhat I take from here is that:\n\n1. Don't expose the https API (duh?)\n2. Don't run anything else on the server explicitly other than Docker. Not sure\nwhat this means for having a gitlab-runner. Actually, I do, see 3.\n3. Looks like it makes sense to run gitlab-runner itself inside a docker\n    container as mentioned [here](https://docs.gitlab.com/runner/install/docker.html).\n    This will allow having a single software with sudo privileges (i.e. Docker)\n4. Overall, still not happy to give docker root privileges. A lot of work\n    can/needs to be done using USER\n5. The way I have overcome this is by not exposing the machine to outside world\n    outside the trusted ports 80, 22 etc. And running the docker registry\n    (advanced, see below) locally only.\n\n### Instructions on how to reproduce LBL CI/CD architecture\n\n1. Install docker\n\nFollow instructions from [docker.com](https://docs.docker.com/install/linux/docker-ce/debian/)\nto install Docker CE stable.Nothing interesting really, once you trust\ndocker.com (and its supply chain) with root on your machine.\n\n2. Run gitlab runner inside a docker container\n\nThis uses the latest gitlab-runner container maintained on docker hub by gitlab.\n\n```bash\ndocker run -d --name gitlab-runner --restart always -v /srv/gitlab-runner/config:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock    gitlab/gitlab-runner:latest\n```\n\n3. Strategy of CI with Docker\n\nWant to run tests under a certain reproducible configuration?\n\n    1. Write a Dockerfile for your setup\n    2. Build docker image from the file.\n    3. Add it to your repo for tracking\n    4. Load them to the CI server\n\n\n     ```bash\n    docker save my-awesome-image | ssh my-docker-running-machine \"docker load\"\n    ```\n\n    5. Update .gitlab-ci.yml to use this image to run tests (see bedrock/.gitlab-ci.yml)\n    6. For advanced registry setup see below\n\n4. Register the gitlab-runner with gitlab server\n\n``` bash\ndocker run --rm -t -i -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register --non-interactive --executor \"docker\" --docker-image iverilog-test:latest --url \"https://gitlab.lbl.gov/\" --registration-token \"\u003cREG_TOKEN\u003e\" --description \"my-docker-runner\" --run-untagged --locked=\"false\"\n```\nThis should successfully register the container and updates /srv/gitlab-runner/config/config.toml.\nHave a look at it.\n\nIf you have a non-standard git hosting service (unlike gitlab.com or github.com),\nyour self-hosted gitlab server may put you in an awkward position with a few things.\n\n5. Certs for https are self-certified, so you would need to add them to the gitlab-runner container\n\n```bash\nscp -pr gitlab.lbl.gov.{pem,crt} mohs:/srv/gitlab-runner/config/certs/.\n```\n\nAs shown [here](https://gitlab.com/gitlab-org/gitlab-runner/issues/3748), copy\ngitlab.lbl.gov.crt to /srv/gitlab-runner/config/certs/.\n\n6. Once the runner inside the container is registered. The docker executor is\nset to execute:\n\n    1. Create cache container to store all volumes as defined in config.toml and Dockerfile of build image (my-awesome-image:latest)\n    2. Create build container and link any service container to build container.\n    3. Start build container and send job script to the container.\n    4. Run job script.\n    5. Checkout your latest commit from your git-repo in: /builds/group-name/project-name/.\n    6. Run any steps you may have defined in .gitlab-ci.yml.\n    7. Check exit status of build script, and report it as FAIL or SUCCESS\n    8. Remove build container and all created service containers.\n\n    Now if your certificates aren't \"legit\", for checking out the code you\n    should set GIT to not verify SSL, as I couldn't get this to work in any other way.\n    `GIT_SSL_NO_VERIFY` to false as shown [here](https://gitlab.com/gitlab-org/gitlab-runner/issues/986)\n\n### Docker tips\n\n1. In case the rootfs is starting to get full, you can move the `/var/lib/docker` into\na separate directory. References: [here](https://stackoverflow.com/questions/40755494/docker-compose-internal-error-cannot-create-temporary-directory), [here](https://forums.docker.com/t/how-do-i-change-the-docker-image-installation-directory/1169)\nand [here](https://linuxconfig.org/how-to-move-docker-s-default-var-lib-docker-to-another-directory-on-ubuntu-debian-linux)\n\n2. Removing containers and images in case of bloat\n\n```bash\n# Remove all stopped containers\ndocker rm $(docker ps -a -q)\n# Remove all containers\ndocker rm -f $(docker ps -a -q)\n# Remove all images\ndocker rmi $(docker images -q)\n```\n\nReference [here](https://stackoverflow.com/questions/40755494/docker-compose-internal-error-cannot-create-temporary-directory)\n\n3. More useful commands\n\n```bash\n# This lists all images\ndocker image ls --all\n# This removes an image\ndocker rmi \u003cimage name\u003e\n# This lists all containers\ndocker container ls --all\n# Lists all docker processes\ndocker ps --all\n# Run a shell attached to the container\ndocker run --rm -i -t my-awesome-image /bin/bash -c 'ls'\n```\n\n4. Useful cheat sheet\n\nDocker cheat sheet [here](https://www.docker.com/sites/default/files/Docker_CheatSheet_08.09.2016_0.pdf)\n\n5. Mounting a device inside docker container\n\n* You can do this automatically per runner basis from /srv/gitlab-runner/config/config.toml\n* Per docker runner you can mount devices with `--device` flag.\n* Here is an example way to pass usb subsystem into the container.\n\n```bash\ndocker run --rm -it --device=/dev/ttyUSB0:/dev/ttyUSB0 mohs.dhcp.lbl.gov/testing_base /bin/bash -c \"miniterm.py\"\n```\n\n6. Effects of migrating CI to github. Check [this repository](https://github.com/ligurio/awesome-ci)\n\n7. Nothing out there that is truly free and steady to use, outside self hosted\ngitlab (which has some features missing like integrating with external repos).\n\nMay have to dish out money to TravisCI or CircleCI or even Gitlab Premium\n(which isn't hosted by us).Looks like Jenkins integration to Gitlab has just\nopened up and looks promising.\n\n8. Automatically building all required Docker images\n\n    1. As Dockerfiles are revision controlled. Upon a change to the them, the\n        images are rebuilt.\n    2. If there is no image cache they are completely rebuilt. And if your\n        requirements are a lot, then it adds time in addition to building your\n        Vivado bitfiles. Especially if you are building things like\n       riscv-toolchain from source :)\n    3. These rebuilds can be cached in a local registry or a place like\n        dockerhub. If you are not the one to be turned-off by running your\n        own registry, you have company.\n    4. Between changes to dependencies the images are cached in the registry,\n        and containers are spawned instantaneously. The new images can be set\n        to be rebuilt on per-git-branch basis so each development branch can\n        have the luxury of its own dependencies.\n    5. This rebuild is in itself done through CI, so a docker engine, running\n        inside another docker engine. This comes with its own good and bad. And\n        information is over [here](https://docs.gitlab.com/ee/ci/docker/using_docker_build.html).\n        This is also the recommended way. See [bedrock/.gitlab-ci.yml] for how\n        this is done.\n    6. Overall, it is important to watch out who is able to commit to this build\n        repo. Because this Docker inside Docker runs as privileged container, it\n        has privileges to modify the parent docker, and that could potentially delete\n        all the containers?!\n    7. These rebuilt images are then pushed to a local registry with a version\n        tag `latest`\n\n### Setting up a docker registry\n\nBasic steps:\n\n1. Run a docker registry\n2. Automatically build Dockerfiles from mohs-basic through another CI instance\nand send them to the registry\n3. Update .gitlab-ci.yml to use images from the registry\n4. Local registry setup with self-signed certificates:\n\n```bash\n# Create a certificate: enter mohs.dhcp.lbl.gov for \"Common Name\", everything else can be gibberish\nopenssl req -newkey rsa:4096 -nodes -sha256 -keyout certs/domain.key -x509 -days 365 -out certs/domain.crt\nsudo cp certs/domain.crt /etc/docker/certs.d/mohs.dhcp.lbl.gov/ca.crt\n\n# Add the self signed certificate to a list of docker certs so that the cert is recognized by docker as it queries the registry\n# After this step the \"local docker machine\" should be able to make a query to the registry\n\n# Below adds .crt to system (mohs's) certificates and updates the system\nsudo cp certs/domain.crt /usr/local/share/ca-certificates/mohs.dhcp.lbl.gov.crt\nsudo update-ca-certificates\n```\n\n### Contribute\n\n* This is an evolving document, please feel free to contribute\n* Rigor is lacking towards gitlab registry end, as I am not aware of any readership,\n    once I am convinced this is being read, I would be happy to put in more detail\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fslaclab%2Fmohs_docker","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fslaclab%2Fmohs_docker","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fslaclab%2Fmohs_docker/lists"}