Overview

trying to find a way to deploy a nutanix vm using ansible playbook. I also need to look into building a RHEL image with packer since I would like installed: Ansible Community Edition NGINX Opensource Dynatrace OneAgent with the NGINX module Eventually the F5 xC ONE agent To test I could deploy everything on one VM that is a flavor of RHEL (if you can't get the real thing) so something like AlmaLinux or Rocky Linux. For this test I'm going to download the AlmaLinux-9.4-x86_64-minimal.iso I'm either utilizing my macbook running Parallels Desktop so I won't go into the details of the setup. I prefer to do this via Docker Desktop but I want to replicate this as close to using Nutanix as I can so my macbook is simulating Nutanix. OR I will be utilizing QNAP Virtualization Station

More notes that I've been jotting down... myapp-ingress.yaml myapp-internal-service.yaml

How to install Kubernetes... Debian Make sure docker is installed sudo docker --version sudo systemctl start docker sudo systemctl status docker sudo apt-get install curl -y curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add curl -s https://api.github.com/repos/kubernetes-sigs/kind/releases/latest| grep browser_download_url | grep kind-linux-amd64 | cut -d '"' -f 4 | wget -qi - chmod a+x kind-linux-amd64 sudo docker ps curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl" curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl.sha256" echo "$(cat kubectl.sha256) kubectl" | sha256sum --check sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl kubectl version --client kubectl version --client --output=yaml sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl gnupg curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg # allow unprivileged APT programs to read this keyring echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ / sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list # helps tools such as command-not-found to work correctly sudo apt-get install -y kubectl

This is the final step of the DevOps Pipeline OPERATE/Environment (80%) Notifications Recovery Logging MONITOR/Infrastructure (100%) Feedback Data Collection Productivity Customers are already telling you whether you’ve built the right thing – you just have to listen. Continuous feedback includes both the culture and processes to collect feedback regularly, and tools to drive insights from the feedback. Continuous feedback practices include collecting and reviewing NPS data, churn surveys, bug reports, support tickets, and even tweets

This has about 10% of RELEASE/Repository Schedule plan Micro-services 100% of DEPLOY/Blue-Green Strategy Configuration Automated deployment Multi-level 20% of OPERATE/Environment Notifications Recovery Logging

DC/OS (the Distributed Cloud Operating System) is an open-source, distributed operating system based on the Apache Mesos distributed systems kernel. DC/OS manages multiple machines in the cloud or on-premises from a single interface; deploys containers, distributed services, and legacy applications into those machines; and provides networking, service discovery and resource management to keep the services running and communicating with each other. https://dcos.io/

A leader in software containerization, Docker is used by 11 million+ developers across the world. Solomon Hykes is its original author and it was released in 2013 by Docker, Inc. As a DevOps tool, Docker helps developers to build, package, and then deploy the codes with ease and speed via containers with needed dependencies instead of virtual machines. It eliminates mundane configuration activities and fosters effective team collaboration. Docker ensures that the same software development environment is maintained across every stage of a DevOps cycle, from development to staging and production. It empowers the developers to create Docker images that they can run in the development environment and operation teams to perform testing and deployments. Features and Benefits: Docker uses OS-level virtualization to deliver applications in packages referred to as a container. It’solates these containers from each other and bundles the software, configuration files, and libraries, making them transferable and more secure. It works easily with GCP and AWS and simplifies cloud migration Docker facilitates distributed development The tool makes it easy to add features and perform fixes Docker runs in Windows, macOS, and Linux It integrates well with deployment pipeline tools like CircleCI, GitHub, etc. It offers both open source and commercial solutions Docker is used by enterprises like Netflix, Adobe, AT&T, PayPal, etc. The term is "container" regardless of whether you're working with Docker Engine or MikroTik's lightweight reimplementation of the technology in RouterOS. Docker neither originated the concept nor created the base technologies in Linux that made it possible. Their implementation is distinguished by being the one that first popularized the Linux container concept by making it easy to apply in practice. In the past, the ROS docs on their container feature misused the term "docker" to refer to the technology generally, and you will find echoes of that misuse here on the forum. Furthermore, there are others who continue to make this confusion for the same reason other brand names have become genericized. I believe it is important to make the distinction because the Docker implementation of containers is different in many ways from the one in RouterOS. Conflating these two unrelated implementations will lead you into misapprehensions, delaying your enlightenment. The first key thing you must understand is that there isn't any proprietary Docker, Inc technology in RouterOS, that I'm aware of. As far as I can tell from my position here as an outsider to their development organization, MikroTik started with nothing more than comes with the generic Linux kernel, then reimplemented everything else you need to have a container engine atop that. That isn't even close to the second time it's been done before; more like the two-dozenth. Occasionally the use of the term "Docker" indicates that the one using it either didn't bother ensuring that their container is portable to other engines, or that they have made purposeful use of some Docker-specific feature, making it non-portable by design. I've never run LibreNMS, so I can't tell you which of these two is the case, if either is. Do I load a lightweight Ubuntu or Debian Docker, and then add LibreNMS via their installation script? Definitely not. Containers are not VMs. I need assistance please with setting environment variables and mountpoints That's documented in the RouterOS manual. What's your difficulty in applying it? This high-level overview of Docker storage tech may help. RouterOS's container engine supports bind mounts only, pointing at directories you create on the USB SSD you spoke of in your original post. RouterOS doesn't have a volume manager as in more featureful container engines, but this lack is inessential from the internal viewpoint of the containerized service. I am not sure to pass through variables typically set up in a yml file to the design used by ROS YAML files are used for several things in the container world, but although none of them apply to RouterOS's indepdendent implementation, there are two standouts in this context, being admin-focused, thus worth a slice of your attention at this early stage in your education, if only so that you can recognize them and adjust as necessary for RouterOS. One is for "compose" files, named after a Docker feature that lets you define multiple containerized services in a single unit so that you can bring them all up and down together. It's since been cloned in a few other engines — and even reimplemented once by Docker, Inc! — but it has yet to appear in RouterOS, and frankly, I doubt it ever will. It's an administration affordance, not an essential backbone feature of containers; while it may be nice to have, only a spoiled snob would consider it a deal-breaker when absent. 😛 Every instance of "yml" on the top-level LibreNMS Docker page is of this type, but the thing is, they're all talking about "sidecar" containers to get additional services you can hook into LibreNMS. As far as I can tell, having never deployed LibreNMS myself, these are not necessary to make LibreNMS itself run. If you need these other services, you can simply add them one at a time as independent containers under RouterOS until you've built up what you need. It isn't as convenient as saying "docker compose up", but them's the downsides of using a bare-bones container engine like the one in RouterOS instead of something full-featured like Docker Engine. The second major admin-facing use of YAML in the container world is for defining Kubernetes clusters, a much higher level thing than compose meant for managing clusters of container engines, even whole data centers full of them. You will find a good many people who want to jump straight from one container to a k8s cluster, but I beg you to help me resist this tendency toward overcomplexity. Google needs k8s; you probably don't, and if you do, it is inadvisable in the highest degree to implement a k8s cluster atop RouterOS.

This has about 75% of TEST/UAT Performance Load Testing Continuous Testing And about 90% of RELEASE/Repository Schedule plan Micro-services

This could include a little of... DEVELOP/Code Shared source code repository Version controls Mainly includes BUILD/Continuous Integration Error Detection Automated tests And starts into TEST/UAT Performance Load Testing Continuous Testing Continuous integration is the practice of checking in code to a shared repository several times a day, and testing it each time. That way, you automatically detect problems early, fix them when they’re easiest to fix, and roll out new features to your users as early as possible.

Infrastructure as Code (IAC): Ansible is a suite of software tools that enables infrastructure as code. It is open-source and the suite includes software provisioning, configuration management, and application deployment functionality.

Source control and collaborative coding: Bitbucket Pipelines brings continuous integration and delivery to Bitbucket Cloud, empowering teams to build, test, and deploy their code within Bitbucket.