Git | Luis Cacho

Update all the git submodules

Thu, 22 Jun 2023 00:00:00 +0000

# Example command
git submodule foreach git pull

References:

¹How to update submodules in git?

https://stackoverflow.com/questions/33714063/how-to-update-submodules-in-git ↩︎

Change author email in commit

Tue, 30 Nov 2021 00:00:00 +0000

Just works in the last commit

git commit --amend --author="John Doe <john@doe.org>"

References:

¹How can I change the author (name / email) of a commit?

https://www.git-tower.com/learn/git/faq/change-author-name-email ↩︎

Update local branch with upstream content

Wed, 11 Aug 2021 00:00:00 +0000

cd $working_dir
git fetch upstream
git checkout main
git rebase upstream/main

Gitkraken Ambassador

Mon, 09 Aug 2021 00:00:00 +0000

Table of Contents

Hello again,

I’m happy to announce that I’m participating in the GitKraken Ambassador program.

For me, it is a joy that the GitKraken team trusts me for this work.

GitKraken Ambassador

I have been a GitKraken advocate even before they launched this program. I always recommend it to all my friends and colleges because I have loved it since the first time I used it, back in 2018.

Now, I’m being named Ambassador to actively promote it in community events, meetings with other Ambassadors, beta-testing of new functionality, etc. Also, I will create some post showing/explaining how I use GitKraken in my job, that is A LOT.

For joining the GitKraken Ambassador team, I received:

Free GitKraken Pro Account ($79 value)
Ambassador Starter Kit: Stickers, Swag & Resources
Access to a private Ambassador Slack Channel
Exclusive Ambassador Content & early access to beta features
Access to GitKraken Product Team to share feedback and get exclusive insight

GitKraken Ambassador Starter Kit

What is GitKraken?

Let’s start defining what is GitKraken for me and how I use it.

GitKraken provides me the easiest, safest, and most powerful way to interact/work with:

Git
GitHub
GitLab,
and more Source Code Management (VCS)

becoming the best complement to manage your source code.

As an Infrastructure consultant, I contribute to Ansible playbooks/roles, Terraform provisioning, Kubernetes/OpenShift manifests, Documentation, and more, but my profile is not necessary as a Developer. I consider myself more a DevOps Practitioner where, from my perspective, I write code for Infrastructure in a declarative way; that being said, my workflow is slightly different from a Developer.

That means I usually do all my code in VSCode. Sometimes I commit using the terminal and sometimes using the Kraken. Once I’m ready to push my changes, I switch to GitKraken to review that I’m in the correct branch/tree/tag, if there are no conflicts, etc. and, then I do push/merge it in a collaborative way and keeping the order that the project requires and that I want to show. That personal workflow always helped me to avoid mistakes in my job.

What I like

GitKraken has a pretty neat interface where it is easy to find all I need for that git workflow.

GitKraken Interface
Multiple git profiles support

GitKraken Profiles 1/2

GitKraken Profiles 2/2
Easy drag and drop Pull-Request/Merge-Request integration

GitKraken Drag & Drop Pull Request

What I don’t like

Sometimes, when my computer has high resources usage, like when I’m running some containers/virtual machines, GitKraken produces a slow down for a bit like some other GUI’s.

Wrapping Up

So, starting today, I’m going to generate content related to Git/Gitkraken, and to achieve this, I will write about how I integrate GitKraken into my daily work.

If you want to start using GitKraken, you can download the Kraken and try it by yourself! Furthermore, I recommend to use my referral code when you sign in.

Happy coding!

Delete git submodule

Sun, 08 Aug 2021 00:00:00 +0000

git submodule deinit -f -- <name_of_submodule>
rm -rf .git/modules/<name_of_submodule>
# Note: The <name_of_submodule> shouldn't have the trailing slash
git rm -f <name_of_submodule>

git commit -m "Deleted submodule xyz"

Example

git submodule deinit -f -- a/submodule
rm -rf .git/modules/a/submodule
git rm -f a/submodule
git commit -m "Deleted submodule a/submodule"

References:

¹How do I remove a submodule?

https://stackoverflow.com/questions/1260748/how-do-i-remove-a-submodule#1260982 ↩︎

Set a hugo blog on Kubernetes

Mon, 18 Jun 2018 00:00:00 +0000

Table of Contents

Overview

Since last year I been trying to become an SRE (Site Reliability Engineer), so I been involved with some emerging technologies, like ansible, docker and on this time with kubernetes.

This time, I will try to explain how I containerized my blog using:

Architecture

So, I take some ideas from here and I modify them and adapt the architecture described to my options.

The principal changes that I made are:

My Kubernetes cluster is running on 2 cloud server on Rackspace Public Cloud
The container registry that I’m using is Quay
Rackspace Public Cloud does not support a Kubernetes LoadBalancer service automatically, so I simulate that behavior adding a Cloud Load Balancer manually after the Kubernetes service provide me the port.

Architecture

Containerized

I use Hugo to deploy my blog, I used to do it as mentioned on this previous post (In Spanish).

Now, as a part of containerize the blog it make sense to me to create two stages as described here:

The first stage is a defined build environment containing all required build tools (hugo, pygments) and the source of the website (Git repository).
The second stage is the build artifact (HTML and assets), from the first stage and a webserver to serve the artifact over HTTP.

Dockerfile

Here is the Dockerfile that containerize the blog:

FROM ubuntu:latest as STAGEONE

# install hugo
ENV HUGO_VERSION=0.41
ADD https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_Linux-64bit.tar.gz /tmp/
RUN tar -xf /tmp/hugo_${HUGO_VERSION}_Linux-64bit.tar.gz -C /usr/local/bin/

# install syntax highlighting
RUN apt-get update
RUN apt-get install -y python3-pygments

# build site
COPY source /source
RUN hugo --source=/source/ --destination=/public/

FROM nginx:stable-alpine
RUN apk --update add curl bash
RUN rm /etc/nginx/conf.d/default.conf
COPY modules/nginx.luiscachog.io.conf /etc/nginx/conf.d/luiscachog.io.conf
COPY --from=STAGEONE /public/ /usr/share/nginx/html/
EXPOSE 80 443

MAINTAINER Luis Cacho <luiscachog@gmail.com>

First Stage

Fetch the lastest Ubuntu image and name as STAGEONE
Install the last available hugo version from source.
Install pygments library to use it for highlighting.
Build the site with hugo and the output is set on /public as a build artifact.

Second Stage

Fetch the lastest stable nginx alpine image.
Update the image and install some utilities.
Delete the default nginx configuration file.
Copy the configuration files needed from the repository root directory.
Copy the build artifact /public from the previous stage (STAGEONE)

My First Contribution to OpenStack project

Thu, 15 Mar 2018 00:00:00 +0000

I been working since last year using Ansible for fun and to trying to get prepared to become a DevOps, so I found an excelent OpenStack project called ARA Records Ansible.

Ansible Logo

ARA Logo

Basically it is a project from the OpenStack community that makes it easier to understand and troubleshoot your Ansible roles and playbooks. If you want more information, please refer to the Documentation Page.

Anyhow, I just found a little bug on the Ansible Role to install ARA ansible-role-ara on Debian based distros and just send the patch to fix it.

Here is the link to my contribution.

And, as I am proud of my first commit on a big project here is the screenshot too:

My First OpenStack Contribution

I feel happy and motivated to still learn about this Open-Source project and a lot more.

😄

Deployment de un sitio estatico con Hugo y Git Hooks

Mon, 05 Mar 2018 00:00:00 +0000

Table of Contents

Motivación

Estoy intentando escribir un poco más en mi blog, ya que noté que muchas veces no lo hacia muy a menudo por que al llegar a la consola de administración de Wordpress, habia que dar bastantes clicks para llegar al menu de “Posts”, además de que cada vez que entraba había un plugin diferente que actualizar, y verificar que nada se rompiera con las nuevas actualizaciónes, en pocas palabras hay que darle bastante mantenimiento a un sitio con Wordpress, y además de eso había que dedicarse a escribir el post.

Otra razón por lo que opté hacer el cambio de plataforma, es que al estar tratando de convertirme en DevOps, es necesario, desde mi punto de vista; tratar automatizar/scriptear la mayoria de tus tareas que realizas día a día, y con Hugo considero que se puede realizar este objetivo también.

Consideraciones

Una vez que decidí migrarme de Wordpress, el siguiente paso era decidir a que plataforma mudarme. De entrada la plataforma que queria probar era un Static Site Generator, aqui otro link de por que usar un Static Site Generator.

Partiendo de lo anterior, las opciones que me parecieron interesantes fueron:

Cada una de las opciones tiene diferentes caracteristicas, que no vamos a discutir en este post, sin embargo las carteristicas que me convencieron de usar Hugo por encima de las otras alternativas fueron:

Consta solamente de un binario, que comparado con las otras posibilidades hay que instalar todo un ambiente de desarrollo/producción.
Es bastante rápido.
Es Multi-plataforma
Tiene diversos temas

Instruciones

Consideraciones técnicas

El ambiente consta de:

1 servidor productivo donde esta instalado hugo, git y un servidor web (apache o nginx) , haremos todos los deployments usando el usuario admin, ojo que no es el usuario root.
1 servidor/equipo de desarrollo, de igual forma que cuenta con hugo y git, en mi caso, es mi computadora personal y mi usuario es luiscachog.
1 cuenta de github.com

Autenticación mediante llaves SSH

El primer paso es realizar el intercambio de llaves SSH entre el equipo de desarrollo y el equipo productivo. Para ello seguimos los siguientes pasos:

Generar la llave SSH, tendrás que contestar algunas preguntas, entre las cuales está si quieres ponerle un password, a lo cual deberas dejarlo en blanco para que no te pida contraseña.
```
luiscachog@dev-server:~$ ssh-keygen
```

Copiar la llave SSH hacia el equipo productivo:

luiscachog@dev-server:~$ ssh-copy-id admin@IP_servidor_productivo

Verificar que te puedas conectar desde tu servidor de desarrollo, con tu usuario al servidor productivo, con el usuario que realizará los deployments.
```
luiscachog@dev-server:~$ ssh admin@162.125.2.30 hostname
```
En este caso, debera de mostrarte el hostname del servidor productivo sin pedirte el password.

Configuración sitio con Hugo

El siguiente paso es configurar nuestro ambiente de desarrollo con Hugo y Git.

Para instalar ambos en Ubuntu o derivados debes de ejecutar:
```
luiscachog@dev-server:~$ sudo apt install hugo git
```
Para tener la version más actualizada de hugo puedes seguir los pasos descritos en este link

Vamos a crear un directorio de trabajo para nuestro sitio estatico

luiscachog@dev-server:~$ mkdir ~/sites
luiscachog@dev-server:~$ cd ~/sites

Crearemos un nuevo sitio usando el comando hugo

luiscachog@dev-server:~$ hugo new site luiscachog.io
Congratulations! Your new Hugo site is created in /home/luiscachog/sites/luiscachog.io.

Just a few more steps and you're ready to go:

1.- Download a theme into the same-named folder.
 Choose a theme from https://themes.gohugo.io/, or
 create your own with the "hugo new theme <THEMENAME>" command.
2.- Perhaps you want to add some content. You can add single files
 with "hugo new <SECTIONNAME>/<FILENAME>.<FORMAT>".
3.- Start the built-in live server via "hugo server".

Visit https://gohugo.io/ for quickstart guide and full documentation.

Cuando termine de correr el comando se podra apreciar los siguientes directorios y archivos

luiscachog@dev-server:~$ cd luiscachog.io
luiscachog@dev-server:~$ ls
archetypes config.toml content data layouts static themes
luiscachog@dev-server:~$ tree
.
├── archetypes
│   └── default.md
├── config.toml
├── content
├── data
├── layouts
├── static
└── themes

6 directories, 2 files

El siguiente paso es agregar un tema, puedes encontrar uno que te guste en https://themes.gohugo.io/
```
git init
git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke

# Edit your config.toml configuration file
# and add the new theme.

echo 'theme = "ananke"' >> config.toml
```
Como recomendación adicional en este paso, puedes realizar un fork del tema que te guste en github para poder realizar modificaciones y proponer cambios al mismo, contribuyendo de esa forma a su desarrollo, para hacerlo, sigue los pasos:
1. Realizar un fork del tema, sigue esta guia para hacerlo.
2. Al realizar el fork, tendras en tus repositorios de github el tema que quieras, por lo que tendras que ejecutar los mismos comandos del punto anterior, pero el repositorio del tema apuntara a tu usario en github
```
git init
git submodule add https://github.com/luiscachog/gohugo-theme-ananke.git themes/ananke
# Edit your config.toml configuration file
# and add the new theme.

echo 'theme = "ananke"' >> config.toml
```
Vamos a crear un post de prueba para verificar que todo esta funcionando correctamente
```
hugo new posts/my-first-post.md
echo "Hola Mundo" >> content/posts/my-first-post.md
```
El comando anterior creara un archivo en la ruta content/posts/my-first-post.md, y el contenido será:
```
---
title: "My First Post"
date: 2018-02-28T12:02:38-06:00
draft: true
---
Hola Mundo!!!
```
Finalmente, probaremos que nuestro sitio estatico con nuestro post se muestren de manera local, en nuestro servidor de desarrollo. Cabe mencionar, que por defecto el comando ‘hugo server’ no mostrará los posts que tengan la opción ‘draft: true’, por ello se agrega la bandera -D
```
luiscachog@dev-server:~$ hugo server -D
```

Configuración del repositorio Git en el servidor de desarrollo 1ra parte

En el paso pasado, realizamos la inicialización del repositorio dentro del directorio del sitio estatico:

luiscachog@dev-server:~$ pwd
/home/luiscachog/sites/luiscachog.io
luiscachog@dev-server:~$ git status
On branch master

Initial commit

Changes to be committed:
 (use "git rm --cached <file>..." to unstage)

 new file: .gitmodules
 new file: themes/ananke

Untracked files:
 (use "git add <file>..." to include in what will be committed)

 archetypes/
 config.toml
 content/
 themes/ananke/

Ahora, para tener el repositorio publico, tenemos que crear el repositorio en github.com y configurarlo como un repositorio remoto

luiscachog@dev-server:~$ git add *
luiscachog@dev-server:~$ git commit -m "First commit"
luiscachog@dev-server:~$ git remote add origin https://github.com/luiscachog/luiscachog.io
luiscachog@dev-server:~$ git push -u origin master

Configuración del repositorio Git en el servidor productivo

Para poder ocupar los hooks de git es necesario hacer una primera copia inicial del repositorio en el que vamos a trabajar, con la particularidad de que el repositorio clonado debe ser del tipo bare.

En nuestro servidor productivo haremos:

admin@prod-server:~$ mkdir sites
admin@prod-server:~$ cd sites
admin@prod-server:~$ git clone --bare https://github.com/luiscachog/luiscachog.io luiscachog.io.git

Configuración del hook

Ya que tenemos nuestro repositorio tipo bare en el servidor productivo vamos a crear el script que mandará a llamar el hook de git.
```
admin@prod-server:~$ cd sites/luiscachog.io.git/hooks
admin@prod-server:~$ vim post-update
```

Y agregamos algo asi:

#!/bin/bash

GIT_REPO=$HOME/luiscachog.io.git
WORKING_DIRECTORY=/var/www/vhosts/luiscachog.io/working_hugo
PUBLIC_WWW=/var/www/vhosts/luiscachog.io/public_html
BACKUP_WWW=/var/www/vhosts/luiscachog.io/backup_html
MY_DOMAIN=luiscachog.io

set -e

rm -rf $WORKING_DIRECTORY
rsync -aqz $PUBLIC_WWW/ $BACKUP_WWW
trap "echo 'A problem occurred. Reverting to backup.'; rsync -aqz --del $BACKUP_WWW/ $PUBLIC_WWW; rm -rf $WORKING_DIRECTORY" EXIT

git clone $GIT_REPO $WORKING_DIRECTORY
mkdir -p $WORKING_DIRECTORY/themes
rm -rf $PUBLIC_WWW/*
/home/admin/bin/hugo -v -s $WORKING_DIRECTORY -d $PUBLIC_WWW -b "http://${MY_DOMAIN}"
trap - EXIT

Damos permisos de ejecución al script

admin@prod-server:~$ chmod +x post-update

Probamos que nuestro script funcione adecuadamente:

admin@prod-server:~$ ~/sites/luiscachog.io.git/hooks/post-update

Cloning into '/var/www/vhosts/luiscachog.io/working_hugo'...
done.
0 draft content
0 future content
4 pages created
0 paginator pages created
0 tags created
1 categories created
in 26 ms

Podras verificar tu nuevo post en la URL de su sitio:
```
http://production_domain_or_IP
```

Configuración del repositorio Git en el servidor de desarrollo 2da parte

Una vez tenemos configurado nuestro repositorio en el servidor de producción, procedemos a agregarlo como repositorio remoto en nuestro servidor de desarrollo

luiscachog@dev-server:~$ cd /home/luiscachog/sites/luiscachog.io
luiscachog@dev-server:~$ git remote add prod admin@IP_servidor_productivo:luiscachog.io
luiscachog@dev-server:~$ git ls-remote prod
d1b0b73528ab3117170ef74e133d0194dd2bc88a HEAD
d1b0b73528ab3117170ef74e133d0194dd2bc88a refs/heads/master

Puedes verificar los repositorios remotos con el comando:

luiscachog@dev-server:~$ git remote -v
origin git@github.com:luiscachog/luiscachog.io.git (fetch)
origin git@github.com:luiscachog/luiscachog.io.git (push)
prod admin@IP_servidor_productivo:luiscachog.io.git (fetch)
prod admin@IP_servidor_productivo:luiscachog.io.git (push)

Ahora cada vez que realizemos un push hacia el remote llamado ‘prod’ se llamara la función del hook.

luiscachog@dev-server:~$ cd /home/luiscachog/sites/luiscachog.io
luiscachog@dev-server:~$ hugo new posts/Testing-Deployment.md
luiscachog@dev-server:~$ echo "Deployment Test" >> content/posts/Testing-Deployment.md
luiscachog@dev-server:~$ git add *
luiscachog@dev-server:~$ git commit -m 'Deployment test with git hooks'

Este es el comando que hace la magia:

luiscachog@dev-server:~$ git push prod master
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 310 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Cloning into '/var/www/vhosts/luiscachog.io/working_hugo'...
remote: done.
remote: Cloning into '/var/www/vhosts/luiscachog.io/working_hugo/themes/hugo-future-imperfect'...
remote: INFO 2018/03/01 03:12:34 Using config file: /var/www/vhosts/luiscachog.io/working_hugo/config.toml
remote: Building sites … INFO 2018/03/01 03:12:34 syncing static files to /var/www/vhosts/luiscachog.io/public_html/
remote:
remote: | EN
remote: +------------------+----+
remote: Pages | 10
remote: Paginator pages | 0
remote: Non-page files | 0
remote: Static files | 3
remote: Processed images | 0
remote: Aliases | 1
remote: Sitemaps | 1
remote: Cleaned | 0
remote:
remote: Total in 44 ms
To admin@IP_servidor_productivo:luiscachog.io.git
 d5b0671..cvc4dee master -> master

Listo ya podemos probar nuestro sitio

http://luiscachog.io

Con esto el siguiente paso que realizare es hacer el deployment de mi servidor para el blog usando Ansible.

Nos Vemos!!!

References: Digital Ocean blog post ¹

Digital Ocean ↩︎