NS8-Generic Containers-: Install Uptime-kuma

App
,
1

In relation to this: Uptime Kuma On Nethserver - Howto - NethServer Community

Let me take you through How to install Uptime Kuma on Nethserver 8,

this method can also be used with any other simple docker container as well

The Installation is based on the Video here:
NethServer 8 Deep Dive: how to run generic containers - YouTube

Install Module Scratchpad from the software Center on the Node you require
image

SSH into the Node you wish to install Uptime on.

confirm you can find scratchpad

find ~scratchpad1 -type f

if scratchpad is installed on the Node, you should get the following response
image

Enter the Scrathpad module by the command below

runagent -m scratchpad1 bash -l

Lets Replace the contents of the docker Images in the scratchpad module with the below command
ps(docker run command basically modified)

podman run --replace \
--name uptime-kuma \
--detach \
--publish 4381:3001 \
docker.io/louislam/uptime-kuma

The scratchpad module will now be running the given Docker image within it.
image

NExt, Lets configure Routes, so that the running docker image, is accessible and available on the web browser

Go to settings, HTTP Routes, and create as follows

image
remeber to select the node in which the scratchpad module was installed and subsequently where the podman run command replaced the contents

COnfigure the Host and or path you require
path/uptime-kuma

image

When the configurations complete, you should be able to access uptime kuma on the chosen host url

image
image784×600 16.4 KB

or can run this command

curl -i https://uptime.domain.org

or

curl -i http://host/uptime-kuma

image

Configuration Persistence and making it run on boot
Making service run at boot

podman generate systemd \
--no-header \
--container-prefix '' \
--new \
uptime-kuma

you should get a response like this

image
image771×609 17.5 KB

above will create the file
/home/scratchpad1/.config/state/fd67770930f29358f3a7356bd00d7da337d0d5d5ff100f6139ca85b89514163d.service

to save the unit to file, ad the -f flag

podman generate systemd -f \
--no-header \
--container-prefix '' \
--new \
uptime-kuma

above will create the file
/home/scratchpad1/.config/state/fd67770930f29358f3a7356bd00d7da337d0d5d5ff100f6139ca85b89514163d.service

image
image996×154 5.94 KB

lets rename the file to human readable and place it to systemd

mv -vf
fd67770930f29358f3a7356bd00d7da337d0d5d5ff100f6139ca85b89514163d.service
…/systemd/user/uptime-kuma.service

then run

systemctl --user daemon-reload

You should now have a persistent installation that will also work on reboot

image
image1432×743 42.6 KB

Some thoughts to the @dev_team , on the scratchpad Module

From the Above understanding, I am using that the scratchpad module will forever be linked to the Uptime kuma module that was created,
Unfortunately, accessing the scratchpad module from the admin dashboard, does not give any information at all on what container or containers are running inside scratchpad,

Requests,

  • Add Dashboard to see/view added Docker containers
  • Add ability to view the defined route for the scratchpad module (host)

Questions
Do backups and restore made on scratchpad also apply to the underlying image

Overall, I did not really get a proper understanding on How to install complex modules, the ones with more than one containers using the above method.

I hope someone from the community who grasped wot help with HowTo on th same note.

5 Likes
2

Hi Martin thank you for this how-to! I think a link to the webinar video where I introduced Scratchpad would be a useful reference.

This is on purpose: Scratchpad is just for an experiment, or a prototype that you should throw away after copying Systemd units to a new module repository, started from Kickstart.

For example, this could be a development path for a ns8 module

  1. Find an interesting project/container
  2. Find a way to run it under NS8, writing Systemd units, surviving reboots
  3. Start a new module, using Kickstart as repository template
  4. Develop integrations with ns8: backup/restore actions, email notifications, LDAP connection, UI
  5. Push to NethForge
1 Like
3

well,
while it might have started as an Experiment, i think it is actually useful, and could be improved to provide the said Values, and serve more usefulness.

I understand while we need and want to have all modules Available on NS8, Not every project should and can become a module for NS8,

Equally, building a module is not that easy.
the building part, is the easy part, troubleshooting and resolving matters arising, that’s the hardest part.

Hopefully with time, after the first NS8 release, the dev team would be more available to help troubleshoot and guide module Development,

I have since built a number of modules, most of which should be at about 95% and others 99% complete, there are just some alitle bits of pains when troubleshooting for errors, that were not there in previous built modules, and the testing process.

I would love to have all as modules, but this got me within less than hour to install uptime, Which is not that a complex docker item, Hopefully in future i could build it as a module, but for now, improving the scratchpad, would help for similar kinds of deployments, and if possible PR issues the module developemnt has no idea how to fix

I am looking to fully migrate to NS8, sooner rather than later, because it accrods me some advantages not in NS7, and for this, i need all the modules and installations i am using on NS7 to be possible in NS8, those that i succeed, hurray, those that i do not… well, NS7 will remain

1 Like
4

A few questions on the same note

  1. How could i use this isntance’s running systemD into a NS8 Module, it would be interesting to see how.
  2. How Can i backup the contents for this installation, and restore them to a fully functioning module, assuming the module is built.
  3. Is it possible to restore this installation into a module if the said module is built
  4. How are Updates to the installation supposed to be done?

IF the answer to 2 and 3 above are yes, and there is a path to that, it would be wonderful,
possibly, we could have more HOWTos, then module built, then if one is already running instance from the Howto, Migrate to the module

1 Like
5

COnsidering to having this built into a Module, should be fairly easy, but funny the easiest have always been the ahrdest.

the module should provide better control, and better integration with Apprise and SocketIO