Our home server can host a couple of applications now. But, remembering the different addresses, ports, and services seems somewhat wrong. In this article, we will solve this situation by deploying a dashboard, that provides links to all our applications.
For this tutorial, I will use the Homer dashboard, but will link some alternatives at the end.
This series is explaining how we are setting up a home server from scratch. You can find links to the previous articles below.
- Intro & Concept
- Hardware & OS
- Time, DHCP, DNS Server
- Git Server
- File, Calendar, Contact Sync
- Application Dashboard
This time, we will automate the last deployment, an application dashboard. This way, we don't need to remember all the deployments.
There are also some more powerful features, that are meant to integrate status notifications and additional information or messages. For now, we will not use this. Please feel free to play around with it afterward.
For our home server, we will use the dashboard to display our applications from the previous articles of this series.
Homer with Ansible and Podman
As you may be aware, I have started an Ansible collection that holds a couple of roles for container deployments. Recently, I added the Homer role to it.
The collection is still under heavy development, and not published to Ansible Galaxy. But, we can use the content anyway.
Let's use some code from there, shall we?
The first thing, we should ensure, that the desired collection is installed. Therefore, we need to adjust the requirements.yml.
As you can see, we can install Ansible collections directly from a Git repository. Since this will pull in the latest commit on the main branch, we might limit it to desired tags or commits.
- name: "ansible.posix"
- name: "community.general"
- name: "community.libvirt"
- name: "containers.podman"
- name: "https://github.com/whiletruedoio/whiletruedoio.container.git"
The next part is our playbook. The collection has an Ansible playbook included, but let's create our own. This way, everything will work the same way as the other deployments.
Just create a new YAML file and use the role of the collection. This is done by referencing the fully-qualified role name, similar to modules from a collection.
This will deploy a pretty standard dashboard without our custom links. That's not exactly what we want.
Fortunately, we can provide our own configuration file. Let's create this one. In case you want to adjust everything to your linking, please have a look at the Homer documentation.
For now, the below example will take care of our already existing deployments.
In addition, we need to edit the playbook for two more things. First, we need to let Ansible know, that we want to have a different configuration file, and we also need to adjust the default port for homer, since it is conflicting with our Nextcloud deployment.
For your convenience, I have added the complete code in the repository, too.
The deployment is straight forward. First, we need to install the dependencies from the above
# Install dependency collections
$ ansible-galaxy collection install -r ansible/requirements.yml
Afterward, we can run the playbook to get Homer installed.
# Install Homer container
ansible-playbook -i IP_ADDRESS, -u USER -k -K ansible/playbooks/deploy_homer_container.yml
That's already it. Just point your browser to http://IP_ADDRESS:5000, and you will be greeted with our brand-new dashboard.
In case you want to add, remove or change a button, you just need to adapt the config file and re-run the playbook. That's already it.
In case, you want to improve this setup even more, I would suggest the following things:
- change the default HTTP port of the Pi-hole deployment to a different port
- change the homer default HTTP port to port 80
- adapt the Homer configuration accordingly
This way, the dashboard will be the default gateway to your home server, and you don't need to remember a single port.
In this article, I have chosen Homer. For me, it is looking okay, feels simple enough and is easy to configure. But, there is a vast amount of alternatives available. If you are looking for a different behavior, more features or just something else, let me suggest some tools to look into.
Dashy has a much more "folder'ish" look to it. For me, it looks a bit too technical. It features on-demand themes, layouts and is configurable via YAML, too.
Heimdall is maybe the most well-known application dashboard for home servers. In addition to a simple dashboard functionality, it provides enhanced application integration. Meaning, you can add information like your Pi-hole status to the bookmarks.
The configuration is done on the page itself interactively.
Dashboard is another application dashboard. The name might be a bit boring, and this also accounts for their design philosophy. It is simple, yet very pleasing. If you are looking for a super sleek, JSON configured dashboard, this might be for you.
The "awesome-selfhosted" list might be an inspiration for you. It is a collection for many self-hosted services, and you can find a couple of dashboards there, too.
This already wraps it up. Our container deployments to make the home server useful are done. I would like to know if you are using this home server and how the articles helped or inspired you.
If you find another application, that should be tackled, I would like to hear from you. I might not put it into this series, but there is a couple of room for more articles about Ansible and Podman. ;)
There is something I want to address here. I removed the "Kubernetes testing ground" from the list. This is mostly related to recent updates in Fedora, which make it hard to run k3s directly on our home server. It is still possible to run Kubernetes in a VM, and I will tackle this in one of the next articles. But it does not really fit into the series anymore.
Therefore, this is the last article for this series. I really hope you enjoyed it and got some inspiration for your home lab. Please let me know what you are doing and how it is working for you.