Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts

Tuesday, 8 October 2024

Working on K8 Identity Management.

The configuration change is ready to be pushed into AWS - please guys let me know when you are ready for me to start pushing this into Dev cluster, then test/access the outcome.. If we are happy with it, then propose a rollout/push into PROD.


Using kubeconfig files


There are three main ways to point kubectl at your kubeconfig files:

1 - The --kubeconfig flag


You can pass a flag on every kubectl command that you run.  This flag will force kubectl to read from the kubeconfig file that you specify.  You can only use one kubeconfig file this way.  Also, you can only specify one instance of this flag on the command line.  This way is a little cumbersome as you have to type this for every kubectl command.

2 - The KUBECONFIG environment variable


You can also set a special environment variable named KUBECONFIG.  The value of this variable points at the kubeconfig file that you would like to use.  This variable can be pointed at multiple kubeconfig files, if you wish.  Just make sure to separate the files with colons (on Linux & Mac) or semi-colons (on Windows).  If you specify multiple kubeconfigs this way, then kubectl will merge them all into one config and use that merged version.

3 - The default config file


By default, the kubectl command-line tool will look for a kubeconfig file simply named config (no file extension) in the .kube directory of the user's profile:

  • Linux:
  • $HOME/.kube/config
  • Windows:
  • %USERPROFILE%\.kube\config
This is the easiest method to use, in my opinion.  Simply place a file in the correct directory, and kubectl will automatically pick it up and use it.

Some useful kubectl commands


#show the full contents of your kubeconfig file
kubectl config view

#show the value of the current-context line of your kubeconfig file
kubectl config current-context

#show all of the Users currently defined in your kubeconfig file
kubectl config get-users

#show all of the Clusters currently defined in your kubeconfig file
kubectl config get-clusters

#show all of the Contexts currently defined in your kubeconfig file
kubectl config get-contexts


kubectl Cheat Sheet

This page contains a list of commonly used kubectl commands and flags.

Kubectl autocomplete

BASH

source <(kubectl completion bash) # setup autocomplete in bash into the current shell, bash-completion package should be installed first.
echo "source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanently to your bash shell.
You can also use a shorthand alias for kubectl that also works with completion:

alias k=kubectl
complete -F __start_kubectl k

ZSH

source <(kubectl completion zsh) # setup autocomplete in zsh into the current shell
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # add autocomplete permanently to your zsh shell

Kubectl context and configuration

Set which Kubernetes cluster kubectl communicates with and modifies configuration information. See Authenticating Across Clusters with kubeconfig documentation for detailed config file information.

kubectl config view # Show Merged kubeconfig settings.


# use multiple kubeconfig files at the same time and view merged config
KUBECONFIG=~/.kube/config:~/.kube/kubconfig2


kubectl config view


# get the password for the e2e user
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'


kubectl config view -o jsonpath='{.users[].name}' # display the first user
kubectl config view -o jsonpath='{.users[*].name}' # get a list of users
kubectl config get-contexts # display list of contexts
kubectl config current-context # display the current-context
kubectl config use-context my-cluster-name # set the default context to my-cluster-name


# add a new user to your kubeconf that supports basic auth
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword


# permanently save the namespace for all subsequent kubectl commands in that context.
kubectl config set-context --current --namespace=ggckad-s2


# set a context utilizing a specific username and namespace.
kubectl config set-context gce --user=cluster-admin --namespace=foo \
&& kubectl config use-context gce


kubectl config unset users.foo # delete user foo

Kubectl apply

Apply manages applications through files defining Kubernetes resources. It creates and updates resources in a cluster by running kubectl apply. This is the recommended way of managing Kubernetes applications on production. See Kubectl Book.

Creating objects

Kubernetes manifests can be defined in YAML or JSON. The file extensions .yaml, .yml, and .json can be used.

kubectl apply -f ./my-manifest.yaml # create resource(s)
kubectl apply -f ./my1.yaml -f ./my2.yaml # create from multiple files
kubectl apply -f ./dir # create resource(s) in all manifest files in dir
kubectl apply -f https://git.io/vPieo # create resource(s) from url
kubectl create deployment nginx --image=nginx # start a single instance of nginx


# create a Job which prints "Hello World"
kubectl create job hello --image=busybox -- echo "Hello World"


# create a CronJob that prints "Hello World" every minute
kubectl create cronjob hello --image=busybox --schedule="*/1 * * * *" -- echo "Hello World"


kubectl explain pods # get the documentation for pod manifests


# Create multiple YAML objects from stdin
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000000"
---
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep-less
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000"
EOF


# Create a secret with several keys
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: $(echo -n "s33msi4" | base64 -w0)
username: $(echo -n "jane" | base64 -w0)
EOF

Viewing, finding resources

# Get commands with basic output
kubectl get services # List all services in the namespace
kubectl get pods --all-namespaces # List all pods in all namespaces
kubectl get pods -o wide # List all pods in the current namespace, with more details
kubectl get deployment my-dep # List a particular deployment
kubectl get pods # List all pods in the namespace
kubectl get pod my-pod -o yaml # Get a pod's YAML


# Describe commands with verbose output
kubectl describe nodes my-node
kubectl describe pods my-pod


# List Services Sorted by Name
kubectl get services --sort-by=.metadata.name


# List pods Sorted by Restart Count
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'


# List PersistentVolumes sorted by capacity
kubectl get pv --sort-by=.spec.capacity.storage


# Get the version label of all pods with label app=cassandra
kubectl get pods --selector=app=cassandra -o \
jsonpath='{.items[*].metadata.labels.version}'


# Retrieve the value of a key with dots, e.g. 'ca.crt'
kubectl get configmap myconfig \
-o jsonpath='{.data.ca\.crt}'


# Get all worker nodes (use a selector to exclude results that have a label
# named 'node-role.kubernetes.io/master')
kubectl get node --selector='!node-role.kubernetes.io/master'


# Get all running pods in the namespace
kubectl get pods --field-selector=status.phase=Running


# Get ExternalIPs of all nodes
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'


# List Names of Pods that belong to Particular RC
# "jq" command useful for transformations that are too complex for jsonpath, it can be found at https://stedolan.github.io/jq/
sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})


# Show labels for all pods (or any other Kubernetes object that supports labelling)
kubectl get pods --show-labels


# Check which nodes are ready
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"


# Output decoded secrets without external tools
kubectl get secret my-secret -o go-template='{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}'


# List all Secrets currently in use by a pod
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq


# List all containerIDs of initContainer of all pods
# Helpful when cleaning up stopped containers, while avoiding removal of initContainers.
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3


# List Events sorted by timestamp
kubectl get events --sort-by=.metadata.creationTimestamp


# Compares the current state of the cluster against the state that the cluster would be in if the manifest was applied.
kubectl diff -f ./my-manifest.yaml


# Produce a period-delimited tree of all keys returned for nodes
# Helpful when locating a key within a complex nested JSON structure
kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'


# Produce a period-delimited tree of all keys returned for pods, etc
kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'


# Produce ENV for all pods, assuming you have a default container for the pods, default namespace and the `env` command is supported.
# Helpful when running any supported command across all pods, not just `env`
for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod -- env; done

Updating resources

kubectl set image deployment/frontend www=image:v2 # Rolling update "www" containers of "frontend" deployment, updating the image
kubectl rollout history deployment/frontend # Check the history of deployments including the revision
kubectl rollout undo deployment/frontend # Rollback to the previous deployment
kubectl rollout undo deployment/frontend --to-revision=2 # Rollback to a specific revision
kubectl rollout status -w deployment/frontend # Watch rolling update status of "frontend" deployment until completion
kubectl rollout restart deployment/frontend # Rolling restart of the "frontend" deployment




cat pod.json | kubectl replace -f - # Replace a pod based on the JSON passed into std


# Force replace, delete and then re-create the resource. Will cause a service outage.
kubectl replace --force -f ./pod.json


# Create a service for a replicated nginx, which serves on port 80 and connects to the containers on port 8000
kubectl expose rc nginx --port=80 --target-port=8000


# Update a single-container pod's image version (tag) to v4
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -


kubectl label pods my-pod new-label=awesome # Add a Label
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # Add an annotation
kubectl autoscale deployment foo --min=2 --max=10 # Auto scale a deployment "foo"

Patching resources

# Partially update a node
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'


# Update a container's image; spec.containers[*].name is required because it's a merge key
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'


# Update a container's image using a json patch with positional arrays
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'


# Disable a deployment livenessProbe using a json patch with positional arrays
kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'


# Add a new element to a positional array
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'

Editing resources

Edit any API resource in your preferred editor.

kubectl edit svc/docker-registry # Edit the service named docker-registry
KUBE_EDITOR="nano" kubectl edit svc/docker-registry # Use an alternative editor

Scaling resources

kubectl scale --replicas=3 rs/foo # Scale a replicaset named 'foo' to 3
kubectl scale --replicas=3 -f foo.yaml # Scale a resource specified in "foo.yaml" to 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # If the deployment named mysql's current size is 2, scale mysql to 3
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Scale multiple replication controllers

Deleting resources

kubectl delete -f ./pod.json # Delete a pod using the type and name specified in pod.json
kubectl delete pod unwanted --now # Delete a pod with no grace period
kubectl delete pod,service baz foo # Delete pods and services with same names "baz" and "foo"
kubectl delete pods,services -l name=myLabel # Delete pods and services with label name=myLabel
kubectl -n my-ns delete pod,svc --all # Delete all pods and services in namespace my-ns,
# Delete all pods matching the awk pattern1 or pattern2
kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod

Interacting with running Pods

kubectl logs my-pod # dump pod logs (stdout)
kubectl logs -l name=myLabel # dump pod logs, with label name=myLabel (stdout)
kubectl logs my-pod --previous # dump pod logs (stdout) for a previous instantiation of a container
kubectl logs my-pod -c my-container # dump pod container logs (stdout, multi-container case)
kubectl logs -l name=myLabel -c my-container # dump pod logs, with label name=myLabel (stdout)
kubectl logs my-pod -c my-container --previous # dump pod container logs (stdout, multi-container case) for a previous instantiation of a container
kubectl logs -f my-pod # stream pod logs (stdout)
kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case)
kubectl logs -f -l name=myLabel --all-containers # stream all pods logs with label name=myLabel (stdout)
kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell
kubectl run nginx --image=nginx -n mynamespace # Start a single instance of nginx pod in the namespace of mynamespace
kubectl run nginx --image=nginx # Run pod nginx and write its spec into a file called pod.yaml
--dry-run=client -o yaml > pod.yaml


kubectl attach my-pod -i # Attach to Running Container
kubectl port-forward my-pod 5000:6000 # Listen on port 5000 on the local machine and forward to port 6000 on my-pod
kubectl exec my-pod -- ls / # Run command in existing pod (1 container case)
kubectl exec --stdin --tty my-pod -- /bin/sh # Interactive shell access to a running pod (1 container case)
kubectl exec my-pod -c my-container -- ls / # Run command in existing pod (multi-container case)
kubectl top pod POD_NAME --containers # Show metrics for a given pod and its containers
kubectl top pod POD_NAME --sort-by=cpu # Show metrics for a given pod and sort it by 'cpu' or 'memory'

Copy files and directories to and from containers

kubectl cp /tmp/foo_dir my-pod:/tmp/bar_dir # Copy /tmp/foo_dir local directory to /tmp/bar_dir in a remote pod in the current namespace
kubectl cp /tmp/foo my-pod:/tmp/bar -c my-container # Copy /tmp/foo local file to /tmp/bar in a remote pod in a specific container
kubectl cp /tmp/foo my-namespace/my-pod:/tmp/bar # Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace my-namespace
kubectl cp my-namespace/my-pod:/tmp/foo /tmp/bar # Copy /tmp/foo from a remote pod to /tmp/bar locally

Note:kubectl cprequires that the 'tar' binary is present in your container image. If 'tar' is not present,kubectl cpwill fail. For advanced use cases, such as symlinks, wildcard expansion or file mode preservation consider using kubectl exec.

tar cf - /tmp/foo | kubectl exec -i -n my-namespace my-pod -- tar xf - -C /tmp/bar # Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace my-namespace
kubectl exec -n my-namespace my-pod -- tar cf - /tmp/foo | tar xf - -C /tmp/bar # Copy /tmp/foo from a remote pod to /tmp/bar locally

Interacting with Deployments and Services

kubectl logs deploy/my-deployment # dump Pod logs for a Deployment (single-container case)
kubectl logs deploy/my-deployment -c my-container # dump Pod logs for a Deployment (multi-container case)


kubectl port-forward svc/my-service 5000 # listen on local port 5000 and forward to port 5000 on Service backend
kubectl port-forward svc/my-service 5000:my-service-port # listen on local port 5000 and forward to Service target port with name <my-service-port>


kubectl port-forward deploy/my-deployment 5000:6000 # listen on local port 5000 and forward to port 6000 on a Pod created by <my-deployment>
kubectl exec deploy/my-deployment -- ls # run command in first Pod and first container in Deployment (single- or multi-container cases)

Interacting with Nodes and cluster

kubectl cordon my-node # Mark my-node as unschedulable
kubectl drain my-node # Drain my-node in preparation for maintenance
kubectl uncordon my-node # Mark my-node as schedulable
kubectl top node my-node # Show metrics for a given node
kubectl cluster-info # Display addresses of the master and services
kubectl cluster-info dump # Dump current cluster state to stdout
kubectl cluster-info dump --output-directory=/path/to/cluster-state # Dump current cluster state to /path/to/cluster-state


# If a taint with that key and effect already exists, its value is replaced as specified.
kubectl taint nodes foo dedicated=special-user:NoSchedule

Resource types

List all supported resource types along with their shortnames, API group, whether they are namespaced, and Kind:

kubectl api-resources

Other operations for exploring API resources:

kubectl api-resources --namespaced=true # All namespaced resources
kubectl api-resources --namespaced=false # All non-namespaced resources
kubectl api-resources -o name # All resources with simple output (only the resource name)
kubectl api-resources -o wide # All resources with expanded (aka "wide") output
kubectl api-resources --verbs=list,get # All resources that support the "list" and "get" request verbs
kubectl api-resources --api-group=extensions # All resources in the "extensions" API group

Formatting output

To output details to your terminal window in a specific format, add the -o(or --output) flag to a supported kubectlcommand.

Output formatDescription
-o=custom-columns=<spec>Print a table using a comma separated list of custom columns
-o=custom-columns-file=<filename>Print a table using the custom columns template in the <filename>file
-o=jsonOutput a JSON formatted API object
-o=jsonpath=<template>Print the fields defined in a jsonpathexpression
-o=jsonpath-file=<filename>Print the fields defined by the jsonpathexpression in the <filename>file
-o=namePrint only the resource name and nothing else
-o=wideOutput in the plain-text format with any additional information, and for pods, the node name is included
-o=yamlOutput a YAML formatted API object
Examples using -o=custom-columns:

# All images running in a cluster
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'


# All images running in namespace: default, grouped by Pod
kubectl get pods --namespace default --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image"


# All images excluding "k8s.gcr.io/coredns:1.6.2"
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'


# All fields under metadata regardless of name
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
More examples in the kubectl reference documentation.

Kubectl output verbosity and debugging

Kubectl verbosity is controlled with the -vor --vflags followed by an integer representing the log level. General Kubernetes logging conventions and the associated log levels are described here.

VerbosityDescription
--v=0Generally useful for this to alwaysbe visible to a cluster operator.
--v=1A reasonable default log level if you don't want verbosity.
--v=2Useful steady state information about the service and important log messages that may correlate to significant changes in the system. This is the recommended default log level for most systems.
--v=3Extended information about changes.
--v=4Debug level verbosity.
--v=5Trace level verbosity.
--v=6Display requested resources.
--v=7Display HTTP request headers.
--v=8Display HTTP request contents.
--v=9Display HTTP request contents without truncation of contents.

Monday, 16 September 2024

How GitHub Advanced Security for Azure DevOps Saves the Day (and Your Reputation)

Let's face it, developers: we've all accidentally committed a secret (or two) to our code repository at some point. Maybe it was an API key, a database password, or that super-secret encryption key you swore you'd never forget. ‍♂️



The problem?  Those exposed secrets can be a hacker's dream come true. A leaked secret can bring your entire application crashing down, wreaking havoc on your data and reputation. Shuddersville.  Many good developers do not pay attention to this critical aspect while working on the code, behaviour which most of the time becomes very costly and painful.

That's where GitHub Advanced Security for Azure DevOps swoops in like a superhero with a cape (well, maybe more like a shield, but you get the idea). This powerful integration brings the muscle of GitHub's security features into your Azure DevOps workflow, so you can identify and squash those secret leaks before they become a disaster.


Here's how GitHub Advanced Security for Azure DevOps saves your bacon:

  • Secret Scanning: It acts like a super-sleuth, scouring your code for any exposed secrets like passwords, tokens, and keys. No more accidental oopsies making it past your commit.
  • Dependency Scanning: Those third-party libraries you love? They can have hidden vulnerabilities. Advanced Security scans your dependencies to expose any weak spots so you can patch them up before they get exploited.
  • CodeQL Code Scanning: This built-in code analysis tool is like a security X-ray for your codebase. It hunts for potential vulnerabilities and coding errors, so you can fix them before they become a problem.

The best part? This security suite integrates seamlessly into your Azure DevOps workflow. No need to jump through hoops or learn a whole new platform. You can find, fix, and prevent security issues all within your familiar Azure DevOps environment. Win-win!

So, ditch the stress of exposed secrets and vulnerable code. Embrace the power of GitHub Advanced Security for Azure DevOps. Your future self (and your security team) will thank you for it.

P.S. Looking for more info? Check out the official documentation to see how to get started with GitHub Advanced Security for Azure DevOps and start building more secure software today!

Tuesday, 2 July 2024

How to LVM resize filesystem Guide

 Increase the size of an LVM logical volume - Step-by-step Guide.

Tested on

Debian (Etch, Lenny, Squeeze)
Fedora (14)
Ubuntu (Hardy, Intrepid, Jaunty, Karmic, Lucid, Maverick, Natty)

Objective

To increase the size of an existing LVM logical volume

Background

Be aware that extending a logical volume does not by itself let you to store more files in a filesystem located on that volume. If that is your aim then you will need to:
  1. increase the size of the underlying block device (the logical volume), then
  2. increase the size of the filesystem to fill the block device.
These instructions cover the first step only. The method for the second step will depend on the type of filesystem (and in some cases there will be no practicable method). See below for further information.

Scenario

Suppose that /dev/vg0/foo is a logical volume of size 80GB. You wish to increase its size by 40GB to 120GB.

Method

A logical volume can be extended using the lvextend command. You can specify either the amount by which you want to increase the size of the volume:
lvextend --size +40G /dev/vg0/foo

or the final size that you want to achieve:
lvextend --size 120G /dev/vg0/foo

If successful you should see a response of the form:
Extending logical volume foo to 8.00 GB
Logical volume foo successfully resized

Testing

Verify the new size of the logical volume using the lvdisplay command:
lvdisplay /dev/vg0/foo

This should give a response of the form:
--- Logical volume ---
LV Name /dev/vg0/foo
VG Name vg0
LV UUID w2q9ZN-hKnN-CLGf-6Z5g-e1QZ-DCKX-1DYZvR
LV Write Access read/write
LV Status available
# open 0
LV Size 120.00 GB
Current LE 30720
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:85

You should not at this stage expect to see any increase in the amount of usable space within whatever filesystem located on the logical volume, for example, as reported by the df command: it is only the size of the underlying block device that has been changed.

Next steps

If the logical volume contains a filesystem then you will probably now want to extend it to fill the newly available space. Filesystems that can be extended include ext2, ext3, ext4, jfs, reiserfs and xfs. See:
Some filesystems cannot be extended, either because their design makes this impracticable or because the necessary software has not been written. In that case your only option is to move the files somewhere else, then recreate the filesystem, then move the files back.

Troubleshooting

Alternatives

lvresize

An alternative to lvextend is to use the lvresize command:
lvresize --size +40G /dev/vg0/foo

or:
lvresize --size 120G /dev/vg0/foo

The difference is that lvextend can only increase the size of a volume, whereas lvresize can increase or reduce it. This makes lvresize more powerful but more dangerous. If you accidentally reduce the size of a volume without first reducing the size of the filesystem contained within it then the filesystem is likely to be damaged irreparably. For scenarios similar to the one described here, lvextend is recommended because mistakes of this type are not then possible.

See also

Tuesday, 25 June 2024

How to install the lasted Terraform with Home Brew on Mac or Ubuntu

 Hello all welcome into my blog. Here you author, on this article I will be sharing my solution around a problem I found today while updating Home brew on my Machine.

This solution applies both to MacOS as to Ubuntu - as long as you have Homebrew installed on you machine. Please, this article assumes, you are experienced with command line and you have homebrew installed and running through your system..

In case, you have not installed on your system,  then please - here on this page check [ Step-by-steps guide to install home brew Mac ] and how to do the same on Linux/Ubuntu .









The above screenshot was captured while, I was updating all libs installed by Homebrew - and noticed that Terraform have a quite outdated version.👌.. It got me thinking.. 

Uhmm, what if I check it out then, brew throw another message on output






This second message, we can clearly see, the message saying quote "We will nor accept any new Terraform releases in homebrew/core" I was a bit confused here. So, I decided to start investigating is .. So my next step was to run the following command to check, the current installed Terraform was accepted as figure out ways to solve the problem.

So, run $ brew doctor command;











Although, brew reported both Terraform and OpenSSL 1.1 as deprecated - lets focus only on Terraform lets talk about OpenSSL in another blog post.

  I removed Terraform currently installed on my system:





Consulting - Terraform Documentation here I done reinstalled Terraform with Homebrew

Using the lasted version.

The lasts steps is to close your terminal and start new session on Terminal and run - the command $ terraform version

Now you have the latest version of Terraform running on Infra. Happy coding 😁😀😄 ..See you all on the next blog post, happy reading.

Saturday, 22 July 2023

Mastering Docker Minified Systems: A Step-by-Step Guide with Real Use Cases

Introduction

Docker is a powerful platform for developing, shipping, and running applications. Minified Docker systems are optimized for size and efficiency, making them ideal for production environments where resources are at a premium.

Step 1: Understanding Docker Basics

Before diving into minified systems, ensure you have a solid understanding of Docker concepts like images, containers, volumes, and networks.

Key Commands:

docker pull [image_name] # Download an image from Docker Hub
docker run -d --name [container_name] [image_name] # Run a container in detached mode

Step 2: Creating a Minified Dockerfile

A minified Dockerfile contains only the essential layers needed to run your application.

Example Dockerfile:

FROM alpine:latest
RUN apk add --no-cache python3 py3-pip
COPY . /app
WORKDIR /app
RUN pip install -r requirements.txt
CMD ["python3", "app.py"]

Step 3: Building and Running Your Minified Container

Build your image with the Docker build command, tagging it appropriately.

Build Command:

docker build -t my-minified-app .

Step 4: Optimizing Your Image

Use multi-stage builds to reduce size and remove unnecessary build dependencies.

Multi-Stage Dockerfile:

# Build stage
FROM python:3.8-slim as builder
COPY requirements.txt .
RUN pip install --user -r requirements.txt
# Final stage
FROM python:3.8-alpine
COPY --from=builder /root/.local /root/.local
COPY . .
CMD ["python", "./app.py"]

Step 5: Managing Data and State

For stateful applications, use volumes to persist data.

Volume Command:

docker volume create my_volume
docker run -d -v my_volume:/data my-minified-app

Step 6: Networking and Communication

Link containers and enable communication between them using Docker networks.

Network Commands:

docker network create my_network
docker run -d --net=my_network my-minified-app

Step 7: Deploying to Production

Deploy your containerized application using orchestration tools like Docker Swarm or Kubernetes.

Step 8: Monitoring and Maintenance

Monitor your containers and systems using tools like Docker stats, cAdvisor, or Prometheus.

Conclusion

Mastering Docker minified systems involves understanding Docker fundamentals, optimizing Dockerfiles, managing data, and deploying efficiently.

Further Learning

Remember, practice makes perfect. Start small, iterate, and gradually incorporate these practices into larger projects.

OBs:

Docker is an open platform for developing, shipping, and running applications. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly. 


With Docker, you can manage your infrastructure in the same ways you manage your applications. By taking advantage of Docker’s methodologies for shipping, testing, and deploying code quickly, you can significantly reduce the delay between writing code and running it in production.

Certainly! Here’s an extensive guide titled “Mastering Docker Minified Systems: A Step-by-Step Guide with Real Use Cases.” ]


This guide provides a foundational understanding of working with minified Docker systems. For more in-depth learning, refer to the provided links and continue exploring real-world use cases. Happy Dockering!

Sunday, 30 July 2017

How To Install qBittorrent 3.3.7 On Ubuntu 16.04, Ubuntu 15.10 And Ubuntu 14.04 Systems


The - qBittorrent is a torrent client, similar to µTorrent, which was recently ported to the Linux systems. Among others, qBittorrent has built-in search engine for searching in the popular BitTorrent sites, has torrent queueing and prioritizing features, has IP Filtering options, provides a tool for creating torrents and bandwidth limitations.




The latest version available is qBittorrent 3.3.7, which has been released, bringing a few changes only:
  • FEATURE: Delete torrent+files with Shift+Delete
  • BUGFIX: Fix 6-hour speedplot point push rate
  • BUGFIX: Avoid spawning a new explorer.exe process when selecting “Open containing folder”
  • BUGFIX: Fix loading of new geoip db due to an artificial size limit
  • BUGFIX: Better error handling and logging with smtp communication
  • SEARCH: Remove KickassTorrents search engine
  • SEARCH: Remove BTDigg search engine
  • SEARCH: Update Torrentz search engine
For more information, see the full changelog.

Installation instructions:

There isn’t any official qBittorrent PPA or repository, but the community maintains one, so that the users can keep their qBittorrent up to date easily.
The below instructions should work on all the supported Ubuntu systems and derivatives: Ubuntu 16.04 Xenial Xerus, Ubuntu 15.10 Wily Werewolf, Ubuntu 14.04 Trusty Tahr, Linux Mint 17.3 Rosa, Linux Mint 17.2 Rafaela, Linux Mint 17.1 Rebecca, Pinguy OS 14.04, Elementary OS 0.3 Freya, Deepin 2014, Peppermint Five, LXLE 14.04, Linux Lite 2.
$ sudo add-apt-repository ppa:qbittorrent-team/qbittorrent-stable
$ sudo apt-get update
$ sudo apt-get install qbittorrent
If you want to remove qbittorrent, do:
$ sudo apt-get remove qbittorrent




How to check for open ports on Linux

Checking for open ports is among the first steps to secure your device. Listening services may be the entrance for attackers who may exploit...