Home

#Welcome to the IoTHarborAnywhere wiki!

NOTE on recent events:

• docker announcements

Introduction

Embedded systems, HPC, cloud, virtualization, cloud (on premises, private and public clouds), enterprise and secure computing and networks, CI/CD practices and process pipeline automation are key to any and all projects I have worked on for over a decade. Full stack, build/compile stacks and kernel builds can take time for setup and configuration, prior to work actually getting done.

Setting up, configuring, maintaining, systems and network services can be time consuming and require time and expertise from design to end of life. Tools and tool stacks, from UML, mind mapping and documentation all take time and to set up, deploy, let alone learn how to integrate into service and systems design processes.

This project is for the architecture, design, deployment, CI/CD, and maintenance of a documented easily portable container infrastructure, to pick up and take to whatever remote or local location to perform work.

This project's purpose is to continue to automate creation of containers and virtual systems, as well as development, test and production deployment of these systems is my current professional focus. These containers, virtual systems, and processes are being architected to easily be able to support all areas of computer science and engineering, including cyber security, embedded systems, HPC, enterprise services and configuration management.

The Harbor container registry will house the containers and images needed for this effort. Containers will be built with packer, docker, buildah and managed with vagrant, podman, skopeo and docker.

Ramdisks can be critical to build processes - especially to evade build caching problems from repeated build processes. This is the reason for maxing out the memory on the hardware platform. Provide enough memory for both the services for Harbor and memory enough to create ramdisks to both speed up build processes, as well as eliminate cacheing problems from repeated build processes. Ramdisks that take more than physical memory, should start writing into swap, on the M.2 NVME disk, which should be not much slower than the ramdisk itself.

Awesome container links

Cool cloud realated Awesome lists

Setting up container dev environments

Setting up a dev environment on a Windows 10 sytem witn Docker Desktop on WSL2 installed Ubuntu 20.04

Setting up a dev environment on Lubuntu 20.04

Setting up a dev environment on a macOS Catalina laptop for building packer recipes

Initial hardware setup for the prototype of the project:

• Odroid H2+
• 32Gb DDR4 memory
• 256Gb M.2 NVME SSD for the OS
• 2T Samsung 960 SATA III ssd for project space (container and project storage)

Bill of Materials - BoM

---

Initial OS setup for the prototype of the project

• Debian 10

Initial project partitioning on the 256Gb M.2 NVME disk

• 2Gb /boot (ext4)
• 64Gb swap
• The rest / (for root)

dkms to get networking up and running properly

2 x 2.5Gb NICs

• https://wiki.odroid.com/odroid-h2/hardware/install_ethernet_driver_on_h2plus

Wireless

• https://wiki.odroid.com/odroid-h2/application_note/howto_wifi_driver_rtl8812au

Initial Harbor setup via 7error docker-harbor project

Discussion on cookiecutter templateing

For the setup and configuration of a custom deployment of the 7error docker-harbor project

CI/CD process discussion

For cookiecutter templating

* For the setup and configuration of a custom deployment of the 7error docker-harbor project

* Single tool containers

• Umbrello

  • clockworkspheres specific
  • external to the project

• cherrytree

  • clockworkspheres specific
    • centos based packer container recipe
  • external to the project

• vym

  • clockworkspheres specific
    • centos based packer container recipe
  • external to the project

• hamster-time-tracker

  • clockworkspheres specific
    • centos based packer container recipe
  • external to the project

• PlantUML

  • clockworkspheres specific
  • external to the project

• ghidra

  • clockworkspheres specific
  • external to the project

• Please note the link pointers to other container collections in the oci-containers project - these links can be used as reference for learning container tech : https://github.com/clockworksspheres/oci-containers/tree/dev/awesome-container-links

* Tool stack containers

#A Note on container layers#

Containers contain 'layers' - when building a container, a 'layer' is created for each line of writing to the container storage. If a layer can be found in the registry being used, it will not rebuild that layer, but pull it to be used in the new container recipe. This makes for faster building of containers that contain multiple sets of write lines - when there is heavy re-use of layers between projects found in the container registry.

• Architecture/design/reverse engineering tools - Umbrello, vym, cherrytree, hamster-time-tracker, PlantUML, ghidra

• Tools for building firmware/emmc embedded images

• PyQt/Pyside2 compile stack - stack to include Qt, SIP, PyQt/Pyside2, Pyinstaller, Installer wrappers (for deb, rpm, pkg, mpkg, etc)

* Single service

• Database
• Web service
• memcached service
• NTP service
• DHCP
• DNS
• mail
• License server

* Service stacks (multiple services connected to make a larger service - ie LAMP, ELK, JAMF, etc)

• LAMP stack
• JAMF stack
• ELK stack
• CI/CD stack

* Basic CI/CD processes discussion for a container

• GoCD
• Jenkins
• ??? - would love suggestions

* Build of a PyQt build stack, for multiple platforms

Stack to include:

• Qt
• SIP
• PyQt/Pyside2
• Pyinstaller (to pull all python dependancies into a single app, so as to not required external dependancies)
• Installer wrapper
  • for Deb packages
  • for rpm packages
  • for macOS packages (luggage?)

OS order for building these build stacks (unless help is offered)

• Debian
• CentOS
• macOS
• RHEL
• Ubuntu

This project would enjoy any possible potential collaboration!

If you are interested in finding out more, please email [email protected]