Articles, notes and random thoughts on Software Development and Technology
To create a ‘hostPath’ PersistentVolume in a single node cluster (do not use in a cluster with more than 1 node):
kind: PersistentVolume
apiVersion: v1
metadata:
name: pv1
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/your-path-for-vol1"
If the above is pv1.yaml, apply with:
kubectl apply -f pv1.yaml
For more info, see the docs here.
Installing the MariaDB chart with Helm on Kubernetes, I ran into issues with permissions on the folder that I created for the PersistentVolume:
INFO ==> ** Starting MariaDB setup **
INFO ==> Validating settings in MYSQL_/MARIADB_ env vars..
INFO ==> Initializing mariadb database…
mkdir: cannot create directory '/bitnami/mariadb/data': Permission denied
INFO ==> Stopping mariadb…
Per similar question here, if you’re manually creating or reusing a PersistentVolume for MariaDB, you need to “chown -R 1001:1001 /pv-dir” on the PV directory, as the MariaDB container runs with userid 1001 and group 1001.
This website running this blog has been running in Docker containers on a small-ish 4GB VPS for the past 9 months pretty much issue free. You can follow by journey to migrate this site to Docker in posts here and here.
Since I’ve been spending time recently getting up to speed with Kubernetes, the next logic step would be to deploy to a Kubernetes cluster, which would give me an opportunity to find out what it takes to run Kubernetes. I’ve looked at managed offerings on Google and AWS, but the cost for a few small personal projects is a little more than I want to spend.
I have a 8GB VPS ready to go, so far installed with Docker and Kubernetes running as a single node cluster, and I’m starting to plan my strategy for migrating to this new server. The first thing I’ve been thinking about is whether I should take my existing Docker images and just deploy to Kubernetes as is. Where I’ve got stuck so far is I don’t know enough about how to run NGINX with WordPress and MySQL in multiple pods, so I think I might install the WordPress Chart using Helm and for the time being not worry about how to do this myself.
The next thing I’ve been looking at is how to configure an Ingress to access different deployed services via different urls. I’ve been looking at setting up Traefik as the Ingress Controller to do this, and will be sharing a post about that config shortly. What I’m interested in is being able to deploy a number of different projects, including my WordPress site, and have them accessed via different urls, and it looks like Traefik will handle this fine.
I plan on writing some further posts as I make this transition over the next couple of weeks.
Gitlab by default runs on port 80. GitLab in a Docker container runs the same as a when natively installed, but to change the port you need to change the config, and change the exposed ports on the container.
First, per steps here, start the container with:
docker run --detach \
--hostname gitlab.example.com \
--publish host-https-port:container-https-port
--publish host-http-port:container-http-port
--publish 22:22 \
--name gitlab \
--restart always \
--volume /srv/gitlab/config:/etc/gitlab \
--volume /srv/gitlab/logs:/var/log/gitlab \
--volume /srv/gitlab/data:/var/opt/gitlab \
gitlab/gitlab-ce:latest
By default host-http-port and container-http-port are 80, and host-https-port container-https-port are 443. Change these to be whatever port you want to run on, but keep each pair the same (e.g. host-http-port and container-http-port = 8090)
When the container is up, start a shell into the running container:
docker exec -it containerid sh
and then edit the config file:
vi /etc/gitlab/gitlab.rb
and add line (at the top is ok):
external_url 'http://localhost:your-new-port-here
setting your-new-port-here to the new port.
Reconfigure the server:
gitlab-ctl reconfigure
gitlab-ctl restart
Done!