Skip to content
This repository has been archived by the owner on Jan 7, 2024. It is now read-only.

[FEAT] Install controller's .deb during image build process #186

Closed
1 task done
pmalek opened this issue Jan 23, 2023 · 7 comments
Closed
1 task done

[FEAT] Install controller's .deb during image build process #186

pmalek opened this issue Jan 23, 2023 · 7 comments
Labels
enhancement New feature or request

Comments

@pmalek
Copy link

pmalek commented Jan 23, 2023

Is this a new feature request?

  • I have searched the existing issues

Wanted change

I've noticed that controller's image that is downloaded during the image build process in here:

curl -o \
/app/unifi.deb -L \
"https://dl.ui.com/unifi/${UNIFI_VERSION}/unifi_sysvinit_all.deb" && \
is not being installed at that stage. This causes the container's startup time to take longer since the .deb has to be installed on every container restart.

This is especially noticeable on slower hardware like Raspberry PI (with slow IO). In the logs below notice that installing takes around 20 seconds and takes between 2 to 4 cores during that time.

2023-01-23T12:39:13.211042462+01:00 cont-init: info: /etc/cont-init.d/10-adduser exited 0
2023-01-23T12:39:13.211130424+01:00 cont-init: info: running /etc/cont-init.d/15-install
2023-01-23T12:39:13.221440560+01:00 *** installing unifi packages ***
2023-01-23T12:39:13.324239234+01:00 Selecting previously unselected package unifi.
2023-01-23T12:39:13.350658105+01:00 (Reading database ... 9470 files and directories currently installed.)
2023-01-23T12:39:13.353030696+01:00 Preparing to unpack /app/unifi.deb ...
2023-01-23T12:39:13.725400998+01:00 Unpacking unifi (7.3.76-19582-1) ...
2023-01-23T12:39:32.540071860+01:00 Setting up unifi (7.3.76-19582-1) ...
2023-01-23T12:39:33.435774326+01:00 invoke-rc.d: could not determine current runlevel
2023-01-23T12:39:33.444156571+01:00 invoke-rc.d: policy-rc.d denied execution of start.
2023-01-23T12:39:33.496826889+01:00 cont-init: info: /etc/cont-init.d/15-install exited 0
2023-01-23T12:39:33.496925407+01:00 cont-init: info: running /etc/cont-init.d/20-config
2023-01-23T12:39:33.558028451+01:00 *** Setting Java memory limit to 2048 ***
2023-01-23T12:39:33.558113987+01:00 *** Setting Java memory minimum to 1024 ***

Reason for change

Slow container startup.

Proposed code change

Install the .deb during process build and remove the installation service at

if [[ ! -d /usr/lib/unifi/bin ]]; then
echo "*** installing unifi packages ***"
export DEBIAN_FRONTEND=noninteractive
dpkg -i /app/unifi.deb
fi

@pmalek pmalek added the enhancement New feature or request label Jan 23, 2023
@github-actions
Copy link

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

@thespad
Copy link
Member

thespad commented Jan 23, 2023

The alternative is 3-5 minute startups for users affected by the overlayfs cow bug.

FWIW it doesn't install on every restart, only on recreation of the container.

@pmalek
Copy link
Author

pmalek commented Jan 23, 2023

Hm, but /usr/lib/unifi/ is not mounted (nor should it be, right?) or mentioned in the README. Hence each time I restart the container it does install it.

I guess to workaround this limitation I could add a mount for that dir but that doesn't feel right 🤔.

(I'm running this on k3s cluster FWIW)

@thespad
Copy link
Member

thespad commented Jan 23, 2023

A restart persists the container filesystem.

@Roxedus
Copy link
Member

Roxedus commented Jan 23, 2023

Hm, but /usr/lib/unifi/ is not mounted (nor should it be, right?) or mentioned in the README. Hence each time I restart the container it does install it.

Correct, it should not be mounted. What this approach gives us, is one less interaction with files on startup, as the alternative is chowning a decent amount of files.

@pmalek
Copy link
Author

pmalek commented Jan 23, 2023

A restart persists the container filesystem.

When running as a plain container, yes. When running on k8s, nope.

@Roxedus
Copy link
Member

Roxedus commented Jan 23, 2023

That is true, however we will stick to the current implementation, as that caters to the largest amount of our users.

@Roxedus Roxedus closed this as completed Jan 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants