DevOps KB Pages

User Story: A user story is a small, self-contained unit of development work designed to accomplish a specific goal within a product. A user story is usually written from the user’s perspective and follows the format: “ As [a user persona], I want [to perform this action] so that [I can accomplish this goal] .” References: https://www.productplan.com/glossary/user-story/#:~:text=A%20user%20story%20is%20usually,can%20accomplish%20this%20goal%5D.%E2%80%9D

You should stop writing Dockerfiles today — Do this instead https://medium.com/@akhilesh-mishra/you-should-stop-writing-dockerfiles-today-do-this-instead-3cd8a44cb8b0

Note: Services can also be defined without a selector label. A service can be directly matched to a pod by defining an endpoint with a static IP that has the same name as the service . The service will then connect directly to that IP. In this case, to troubleshoot the service, check if there is an endpoint in the cluster with the same name as the service. References: https://komodor.com/learn/kubernetes-service-examples-basic-usage-and-troubleshooting/#:~:text=Note%3A%20Services%20can%20also%20be,connect%20directly%20to%20that%20IP.

In Kubernetes a service always enables its network access to a pod or set of pods Services will select the pods based on their labels and when a network is made to those services it selects all Pods in the cluster matching the service’s selector and will choose one of them, and then will forwards the network request to it.   References: https://medium.com/avmconsulting-blog/service-types-in-kubernetes-24a1587677d6

These are collection of educational Kubernetes videos: How does Kubernetes create a Pod: https://www.youtube.com/watch?v=BgrQ16r84pM imperative vs declarative: https://www.youtube.com/watch?v=shqiLgbzIJY YAML File Explained - Deployment and Service: https://www.youtube.com/watch?v=qmDzcu5uY1I

Instead of memorizing all the Kubernetes configuration yaml Kind templates you may use the imperative commands to generate them.  To generate Kubernetes KIND templates simply use the Imperative wtih dry-run.  Depending on the command the dry-run can either be applied on the client side or on the server (api) side.   "Imperative commands are great for learning and interactive experiments, but they don't give you full access to the Kubernetes API. They're more commonly used to create YAML manifests and objects on the go. Declarative commands are useful for reproducible deployments and production." Here is an example of how to generate pod kind, YAML configuration file. kubectl run nginx --image=nginx:latest -o yaml --dry-run=client Here is an example of how to generate a service kind, YAML configuration file. kubectl create service clusterip my-svc --clusterip = "None" -o yaml --dry-run = client When working with declarative commands, you'll need a YAML m...

 

 Dockers/Kubernetes are a glorified chroot and cgroups ;) Root and Chroot In a Unix-like OS, root directory(/) is the top directory. root file system sits on the same disk partition where root directory is located. And it is on top of this root file system that all other file systems are mounted. All file system entries branch out of this root. This is the system’s actual root. But each process has its own idea of what the root directory is. By default, it is actual system root but we can change this by using chroot()system call. We can have a different root so that we can create a separate environment to run so that it becomes easier to run and debug the process. Or it may also be to use legacy dependencies and libraries for the process. chroot changes the apparent root directory for the current running process and its children. cgroups- Isolate and manage resources Control groups(cgroups) is a Linux kernel feature which limits, isolates and measures resource usage of a group of p...

  Test node connection from ansible controller You can use the Ansible cli with -m ping or -m win_ping to test the node connection (if it's a container/awx) -> Connect to the awx_task container  "docker exec -it awx_task bash". edit the vi "/etc/ansible/hosts"  file, add the test node in the file (anywhere is fine) then don't forget to remove it after the test is done. then run this test command(s). (Replace the values inside the brackets <x> as needed.) (to test a linux machine):  ansible <target-node-name>  -m ping -u '<username>' --ask-pass #TODO windows Next test with become=yes (SUDO) elevated: ansible <target-node> -m ping -u 'autoadm' --ask-pass -b -become-user=root -K next test facts (setup) module ansible < target-node>  -m setup -u 'autoadm' --ask-pass -b -become-user=root -K References: https://docs.ansible.com/archive/ansible/2.3/become.html

Ansible AWX Inventory: Setting up AWX inventory script: Python Script to read the HTTP REST API #!/usr/bin/env python3 # -*- coding: utf-8 -*- import os import re import urllib import argparse import ssl import sys #Python 3.0 and later from urllib.request import urlopen import json parser = argparse.ArgumentParser(      description='Script to obtain host inventory from AD')      parser.add_argument('--list', action='store_true',      help='prints a json of hosts with groups and variables') parser.add_argument('--host', help='returns variables of given host') args = parser.parse_args() if __name__ == '__main__':      data = urllib.request.urlopen("http://nodesvcserver/ansible/GetWorkstations?$adgroupmemberlist=QA_Workstations&$flushcache=true").read()      output = json.loads(data)      print(json.dumps(output)) How payload/model looks like: Reference: https://de...