About This Club
DevOps is a set of practices that brings together software developers and IT operations teams to shorten the systems development life cycle through collaboration, automation, and continuous delivery. It is a cultural philosophy that emphasizes communication and shared responsibility to improve the speed, quality, and efficiency of software development and delivery.
What's new in this club
-
Ansible
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
-
Kubernetes
-
Kubernetes
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
-
shadowmac joined the club
-
Cowboy Denny joined the club
-
DevOps:Continuous Operations
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
-
DevOps:Continuous Testing
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
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/
-
Docker
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.
-
DevOps:Continuous Deployment
This has about 75% of TEST/UAT Performance Load Testing Continuous Testing And about 90% of RELEASE/Repository Schedule plan Micro-services
-
DevOps:Continuous Delivery
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.
-
Ansible
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.
-
Bitbucket
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.
-
circleci
Continuous Integration: CircleCI is a purpose-built CI/CD solution that focuses on performance and extensibility, providing a large number of Orbs, or plugins, that integrate with common DevOps tools to automate application development.
-
GitHub
Owned by: Microsoft Source control and collaborative coding: GitHub is used by developers and companies to build, ship, and maintain software. It makes it possible to collaborate and share code and keep tabs of what's changed along the way. (This process can make it easy to track down, say, when or how a bug was introduced.)
-
GitLab
Owner: OpenSource Source control and collaborative coding: As a single application for the complete DevOps lifecycle, GitLab is: Comprehensive: Visualize and optimize your entire DevOps lifecycle with platform-wide analytics within the same system where you do your work. GitLab is more secure than GitHub, whereas GitHub is less secure as it doesn't have License Compliance. GitLab is a cloud-native application, whereas GitHub is used to share work in front of the public.
-
Jenkins
Owner: Opensource Continuous Delivery: Open source automation server which enables developers around the world to reliably build, test, and deploy their software. Jenkins is an application that monitors executions of repeated jobs, such as building a software project or jobs run by cron. Jenkins deployments generally involve self-hosting, where the users oversee servers in their own data centers.
-
Kubernetes
Production-identical environments for development: Developers use open source tools like Kubernetes to provision individual development environments. Coding against virtual, disposable replicas of production helps you get more work done.
-
Progress Chef
Infrastructure as Code (IaC): Progress Chef is a configuration management tool written in Ruby and Erlang. It uses a pure-Ruby, domain-specific language for writing system configuration "recipes".
-
puppet
Infrastructure as code (IaC): Puppet is a tool that helps you manage and automate the configuration of servers. When you use Puppet, you define the desired state of the systems in your infrastructure that you want to manage.
-
Terraform
Infrastructure as code: HashiCorp Terraform is an infrastructure as code (IaC) software tool that allows DevOps teams to automate infrastructure provisioning using reusable, shareable, human-readable configuration files. The tool can automate infrastructure provisioning in both on-premises and cloud environments.
-
Docker
Pretty cool way of creating a home lab is utilizing Container Station on a QNAP NAS device which offers Docker and LXD. My goal is to test NGINX as a loadbalancer and what I have to use is... 1 QNAP 6bay NAS 1 QNAP 2bay NAS **both running Container Station I'm running three NGINX Containers on the QNAP 6bay and using bridge networking and assigning static IPs 192.168.10.101 192.168.10.102 192.168.10.103 On the 2bay NAS I'm running my pool members which are LAMP web servers 192.168.10.121 192.168.10.122 To build the alpine linux docker containers I ssh to the 2bay NAS [scode lang="{language}"]mkdir -p alpine-sshd cd alpine-sshd/ touch Dockerfile[/scode] [scode lang="{language}"]vi Dockerfile FROM alpine:latest LABEL maintainer="hosang i.t. [email protected]" RUN apk add --update --no-cache openssh RUN echo 'PasswordAuthentication yes' >> /etc/ssh/sshd_config RUN adduser -h /home/dennis -s /bin/sh -D dennis RUN echo -n 'dennis:somepassword!' | chpasswd ENTRYPOINT ["/entrypoint.sh"] EXPOSE 22 COPY entrypoint.sh /[/scode] [scode lang="{language}"]vi entrypoint.sh #!/bin/sh ssh-keygen -A exec /usr/sbin/sshd -D -e "$@"[/scode] [scode lang="{language}"]chmod +x -v entrypoint.sh[/scode] [scode lang="{language}"]docker build -t alpine-sshd .[/scode] To build the ubuntu linux docker containers I ssh to the 2bay NAS [scode lang="{language}"]mkdir -p ubuntu-sshd cd ubuntu-sshd/ touch Dockerfile[/scode] [scode lang="{language}"]vi Dockerfile # Download base image ubuntu 22.04 FROM ubuntu:22.04 LABEL maintainer="hosang i.t. [email protected]" LABEL version="0.1" LABEL description="This is a custom Docker Image for PHP-FPM and Nginx." # Disable Prompt During Packages Installation ARG DEBIAN_FRONTEND=noninteractive # Update Ubuntu Software repository RUN apt update # Install nginx, php-fpm and supervisord from ubuntu repository RUN apt install -y nginx php-fpm supervisor openssh RUN rm -rf /var/lib/apt/lists/* RUN apt clean # Define the ENV variable ENV nginx_vhost /etc/nginx/sites-available/default ENV php_conf /etc/php/8.1/fpm/php.ini ENV nginx_conf /etc/nginx/nginx.conf ENV supervisor_conf /etc/supervisor/supervisord.conf # Enable PHP-fpm on nginx virtualhost configuration COPY default ${nginx_vhost} RUN sed -i -e 's/;cgi.fix_pathinfo=1/cgi.fix_pathinfo=0/g' ${php_conf} && echo "ndaemon off;" >> ${nginx_conf} #Copy supervisor configuration COPY supervisord.conf ${supervisor_conf} RUN mkdir -p /run/php RUN chown -R www-data:www-data /var/www/html RUN chown -R www-data:www-data /run/php # Volume configuration VOLUME ["/etc/nginx/sites-enabled", "/etc/nginx/certs", "/etc/nginx/conf.d", "/var/log/nginx", "/var/www/html"] # Copy start.sh script and define default command for the container COPY start.sh /start.sh CMD ["./start.sh"] # Expose Port for the Application EXPOSE 80 443 22[/scode] [scode lang="{language}"]vi default server { listen 80 default_server; root /var/www/html; index index.html index.htm index.nginx-debian.html; server_name _; location / { try_files $uri $uri/ =404; } location ~ .php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.1-fpm.sock; } }[/scode] [scode lang="{language}"]vi supervisord.conf [unix_http_server] file=/dev/shm/supervisor.sock ; (the path to the socket file) [supervisord] logfile=/var/log/supervisord.log ; (main log file;default $CWD/supervisord.log) logfile_maxbytes=50MB ; (max main logfile bytes b4 rotation;default 50MB) logfile_backups=10 ; (num of main logfile rotation backups;default 10) loglevel=info ; (log level;default info; others: debug,warn,trace) pidfile=/tmp/supervisord.pid ; (supervisord pidfile;default supervisord.pid) nodaemon=false ; (start in foreground if true;default false) minfds=1024 ; (min. avail startup file descriptors;default 1024) minprocs=200 ; (min. avail process descriptors;default 200) user=root ; [rpcinterface:supervisor] supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface [supervisorctl] serverurl=unix:///dev/shm/supervisor.sock ; use a unix:// URL for a unix socket [include] files = /etc/supervisor/conf.d/*.conf [program:php-fpm8.1] command=/usr/sbin/php-fpm8.1 -F numprocs=1 autostart=true autorestart=true [program:nginx] command=/usr/sbin/nginx numprocs=1 autostart=true autorestart=true[/scode] [scode lang="{language}"]vi start.sh #!/bin/sh /usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf[/scode] [scode lang="{language}"]chmod +x start.sh [/scode] [scode lang="{language}"]docker build -t nginx-image .[/scode] [scode lang="{language}"]mkdir -p /var/webroot docker run -d -v /var/webroot:/var/www/html -p 8080:80 --name test-container nginx-image[/scode] Create index.html test page [scode lang="{language}"]echo ' Nginx and PHP-FPM 8.1 inside Docker Container with Ubuntu 22.04 Base Image ' > /var/webroot/index.html [/scode] Test by running these commands [scode lang="{language}"]curl server-ip:8080 curl -I server-ip:8080[/scode]
-
Docker
Coding against virtual, disposable replicas of production helps you get more work done. Introduction: A Docker private registry is a valuable tool for managing and distributing Docker images within your organization. It allows you to store, share, and control access to container images privately. This document outlines the step-by-step process to set up a Docker private registry on an AlmaLinux system. Step 1: Docker Installation: Add the Docker repository: Use the dnf config-manager command to add the Docker repository for CentOS. dnf config-manager --add-repo=docker-ce.repo Verify the repository is added: Check the available repositories using dnf repolist -v. dnf repolist -v Install Docker: Use dnf install docker-ce to install Docker. dnf install docker-ce Start Docker: Use systemctl start docker systemctl start docker Enable Docker: Use systemctl enable docker to enable the Docker service. systemctl enable docker Status of Docker: Use systemctl status docker systemctl status docker Check Docker version: Verify the Docker installation with docker — version. docker — version Step 2: Registry Container Setup: Create a directory for registry storage: Use mkdir /docker_repo to create a directory for registry storage. mkdir /docker_repo Run the Docker registry container: Start the Docker registry container with the appropriate options, such as volume mappings and environment variables. docker run --detach --restart=always --name registry --volume /docker_repo:/docker_repo --env REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY=/docker_repo --publish 5000:5000 registry Verify the container status: Check the status of the registry container using docker ps. docker ps Check that port 5000 (the port you configured) is listening with netstat netstat -tlnp | grep :5000 Step 3: Install a TLS Certificate: Create directory for certs mkdir /certs Assign IP to hostname using the /etc/hosts file cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.222.134 hosangit.almalinux Generate a TLS certificate: Use the openssl req command to generate a self-signed TLS certificate with the appropriate subject alternate name (SAN). openssl req -newkey rsa:4096 -nodes -sha256 -keyout /certs/hosangit.almalinux.key -addext "subjectAltName = DNS:hosangit.almalinux" -x509 -days 365 -out /certs/hosangit.almalinux.crt sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /certs/hosangit.almalinux.key -out /certs/hosangit.almalinux.crt You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:MI Locality Name (eg, city) [Default City]:Flint Organization Name (eg, company) [Default Company Ltd]:HIT Organizational Unit Name (eg, section) []:DevOps Common Name ()eg, your name or your server's hostname) []:hosangit.almalinux Email Address []: [email protected] Save the certificate: Store the generated certificate and private key files in the /certs directory. Step 4: Nginx Setup: Install Nginx: Use dnf install nginx to install the Nginx web server. dnf install nginx -y Configure Nginx: Edit the Nginx configuration files to set up a reverse proxy for the Docker registry. vi /etc/nginx/nginx.conf #add this line at http section client_max_body_size 2048m; vi /etc/nginx/conf.d/hosangit.almalinux.conf server { listen 80; server_name hosangit.almalinux; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name hosangit.almalinux; # ssl params ssl_certificate /certs/hosangit.almalinux.crt; ssl_certificate_key /certs/hosangit.almalinux.key; ssl_protocols TLSv1.2; location / { proxy_pass proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 600; } } Restart Nginx: Restart the Nginx service to apply the configuration changes. systemctl stop firewalld.service systemctl disable firewalld.service setenforce 0 systemctl restart nginx curl -kIL http://hosangit.almalinux/v2/ Step 5: Push Image to Private Registry: Run a sample container: Start a container using the docker run command. docker run --name webserver --detach nginx docker exec -it webserver /bin/bash apt update apt install iproute2 iputils-ping net-tools -y edit daemon.json vi /etc/docker/daemon.json { "insecure-registries" : ["https://hosangit.almalinux"] } mkdir -p /etc/docker/certs.d/hosangit.almalinux cp /certs/hosangit.almalinux.crt /etc/docker/certs.d/hosangit.almalinux/ systemctl restart docker docker image ls Commit the container: Use docker commit to create a new image from the running container. docker commit webserver nginx Tag the image: Assign a new tag to the image using docker tag. docker tag nginx ahosan1.almalinux/nginx docker image ls Push the image: Push the image to the private registry using docker push. docker push hosangit.almalinux/nginx curl -kL https://hosangit.almalinux/v2/_catalog --run in one tab docker logs -f registry --run in one tab tail -1000f /var/log/nginx/access.log Step 6: Pull & Push Images at Private Registry: Verify the private registry: Check the repositories available in the private registry using curl. Pull and tag the image: Pull an image from a public repository and tag it for the private registry. Push the image to the private registry: Use docker push to push the image to the private registry. Verify image availability: Check that the pushed image is available in the private registry. Step 7: Pull & Push Images from Remote Host: Configure remote host: Update the /etc/hosts file on a remote host to resolve the private registry hostname. Configure Docker on the remote host: Configure Docker on the remote host to use the private registry as a mirror. Restart Docker on the remote host: Restart the Docker service on the remote host to apply the configuration changes. Pull images from the remote host: Pull images from the private registry on the remote host. Step 8: Delete Image from Private Registry and Push Images from Remote: Delete image from private registry: Remove an image from the private registry. Restart the registry container: Restart the registry container to reflect the changes. Check the registry status: Use curl to verify the repositories in the private registry. Delete and push images from a remote host: Delete and push images from the private registry on a remote host. Verify image availability: Confirm that the images are pushed and available in the private registry. Conclusion: Setting up a Docker private registry on AlmaLinux involves multiple steps, including Docker installation, registry container setup, TLS certificate generation, Nginx configuration, image management, and interaction between local and remote hosts. Following these steps allows you to create a secure and controlled environment for storing and distributing Docker images within your organization.
-
DevOps:Continuous Integration
This includes PLAN/Requirements Workflow Planning Tasks lists Sprints Also touches on DEVELOP/Code Shared source code repository Version controls
-
Jira
A great practice is continuously gathering user feedback, organizing it into actionable inputs, and prioritizing those actions for your development teams. Look for tools that encourage “asynchronous brainstorming” (if you will). It’s important that everyone can share and comment on anything: ideas, strategies, goals, requirements, roadmaps and documentation
-
Miro
From idea to next big thing, make it happen in Miro. Miro has rich, ready-to-use native capabilities for teams of every size to build out their vision with a creative, collaborative edge. That means supporting workflows in every corner of your business. A quick demo from coderdave
-
Mural
Work with your team in a shared and dynamic visual environment
Who's Online (See full list)
- There are no registered users currently online