BareOS server set #94 #383
Conversation
Multi Container BareOS server set Rock-on containing: - Director Service (overall controller). - Catalog Service (Postgres DB for Director). - Storage Service (Back-end Storage for Director and File (client) services). - Web-UI Service (Director interface). Uses custom docker images at https://hub.docker.com/u/barcus/ as no official docker images are available.
Development ongoingAssumes latest testing branch and requires pending-review PR: rockstor/rockstor-core#2888 Getting there as we now have 2 of the 4 containers persisting: Director container has an outstanding config issue: Web-UI container also has a config issue: [EDIT linking to an imidiate upstream (barcus/bareos docker image repo) issue with the same error reported: https://github.com/barcus/bareos/issues/156] |
Director config issue:Likely we need to have some email info/config here as this is assumed by the docker-startup script: There is similarly email config for /etc/bareos/bareos-dir.d/messages/Daemon.conf: Development notes:Wiping all config to re-test initial install of this in-development Rock-on (DO NOT USE IN PRODUCTION). Director terminal (bconsole) |
- BAREOS_SD_PASSWORD director & storage containers. - Place-holder ADMIN_MAIL (director). - WEBHOOK_NOTIFICATION=true (director) to avoid/disable smtp config for now. - BAREOS_DIR_HOST to bareos-webui.
|
As from the last commit we have only the bareos-webui container restarting: With the previously referenced upstream issue indicating the need for an additional container to provide php-fpm (barcus/bareos#156 (comment)) presumably referencing the docker file here: https://github.com/barcus/docker-php-fpm-alpine/blob/master/Dockerfile The above barcus php-fpm container definition is derived from https://hub.docker.com/_/php (search "php:-fpm") via:
PHP on GitHub: https://github.com/php/php-src The following is older but has hints on how this php-fpm container fits in, and an additional volume for bareos-webui! https://github.com/barcus/bareos/blob/master/docker-compose-alpine-pgsql.yml |
Required by bareos-webui 22 onwards to provide php-fpm. These two webui containers share volumes, via --volumes-from, and an associated launch_order. Additionally we specify a BareOS 'WebUI' data Share to host the website data files that these two container use. These files are installed by the bareos-webui container docker-entrypoint.sh.
Current state of this branchWith a now slightly different bareos-webui error: |
|
Currently requires at least rockstor 5.0.14-0 for testing/development as depends on two multi-container improvements added in this release. |
Rockstor forces unique share allocation, however - bareos-webui-php-fpm needs /var/www/html on web-data but web-data is populated by bareos-webui: and - bareos-webui populates web-data via /usr/share/bareos-webui Plus, bareos-webui requires bareos-webui-php-fpm so the later must start before the former. Have bareos-webui-php-fpm establish bareos-webui volumes, and add share duplicate mount it requires via opts -v. Working around Rockstor repeate share use limitation. Then have bareos-webui inherit via opts (--volumes-from bareos-webui-php-fpm) all 3 volumes. Only two of which it is required to share with it's php-fpm counterpart. We assume no side effects from: "/mnt2/bareos-webui-data:/var/www/html" applied via inheritance within bareos-webui container. Currently, requires dictating a share name !!
|
We have an unfortunate anomaly re incompatible mount points between the dedicated php-fpm container, and the bareos-webui container that depends upon it. Work-around in progress/testing to facilitate approaching the outstanding failure in docker name resolution observed in bareos-webui via: via: |
Diagnosis of bareos-webuiWe start with restart and nginx doesn't like a config and so we have a perpetual container restart, ergo we can examine via: I.e. run, interactively (-it) a shell, as entry point: avoiding our default https://github.com/barcus/bareos/blob/master/webui/22-alpine/docker-entrypoint.sh which ends with trying to starting nginx via: https://github.com/barcus/bareos/blob/master/webui/22-alpine/Dockerfile
interactive and override CMD (nginx) via sh: |
suspect insufficient docker network setupBut bareos-webui container looks to be unable to resolve bareos-webui-php-fpm container. |
Our Bareos-webui container uses bareos-webui-php-fpm as its fastcgi server via `fastcgi_pass bareos-webui-php-fpm:9000;`. Remove director to bareos-webui-php-fpm docker network and add dedicated bareos-webui to bareos-webui-php-fpm to enable private use of the php-fpm by bareos-webui. Resolving a prior failure to resolve the php-fpm containers docker name.
Current state of this branchSo we now have all containers starting, and non restarting. We also now have the Bareos web-ui login screen showing up:
But there remains an issue re php network name resolution for the director. Indicated via php error post WebUI login. When trying to login using the 'admin' user hardwired and our configured BareOS WebUI password, the browser displays the following: |
|
Follow-up on last comment content: it seems that the php-fpm container, a newer dependency of the bareos-webui container, also need to resolve 'bareos-director' via docker networks container name resolution: Our |
Clean-up prior to fresh install testing:During development we can end-up with some kipple: |
It appears that we need this network in order that the PHP code this container carries can also resolve our director. We have a current limitation regarding unique `source_container` network config entries, which prevents us from simply having `bareos-webui-php-fpm` as an additional source_container entry in the "bareos-director" network. This was encountered when adding the bareos-webui network.
|
With the last commit in this branch we now have what looks to be our first apparently functional BareOS Web-UI with our in-development BareOS server set Rock-on: Dashboard (landing page post login)
Default Pools (Storage container) config:
|
|
We may want to include the previously intentionally omitted bareos-fd container as our existing default director has, pre-configured, a Catalog backup Job:
Which when run fails as it depends on a file service: which we were to consider separately via: "BareOS File" #378
|
|
The director default config, re bareos-fd (file deamon client) is established via sed edit of presumably apline or upstream config: https://github.com/barcus/bareos/blob/master/director-pgsql/22-alpine/docker-entrypoint.sh
|
The default config of our director container includes an expectation of a local 'File' (Client) service: used in a pre-configured Catalog backup task and what looks like a buggy config backup setup. Includes: - prior omission to define BAREOS_SD_HOST in director container. - incidental rationalising/reduction on user text.
Current state of this branch:We now have 6 non-restarting containers: And functional director-to-storage and director-to-file (local client) communications. But have a remaining, potentially problematic last network to establish between storage and file containers: E.g. when initiating a build-in back-up task we get the following log (read from bottom to top): Indicating a need for the File service/container to be able to resolve the Storage service/container by name. But we may have a limitation re no duplicate "source_container" entries in our rock-net / "container_links" capability. |
|
Notes on upstream (docker-container author) bugs:
now results in essentially a failed MyCatalog pre-DB-dump script thus: Temp work-around until upstream PR can be presented: hand edit via: [EDIT] It may be this particular sed is not longer needed at all, given that it now defaults to using only the catalog name (Default "MyCatalog"). |
|
The joys of a solution that requires 6 independent building blocks and a whole lot of glue to stick them together ... |
|
@Hooverdan96 Indeed, but I needed some exercise re rock-ons anyway :). No worries re confusion: I'm just making notes on what might be needed in our docs if I don't get around to upstreaming some miss-configurations I've found in the latest containers I experimenting with here. I may end-up rolling my own docker images for this in the end. But there are few options and no official ones I can find: plus these have 100K pulls and have been around for 7 years or so. As such I'm thinking of just upstreaming fixes I find when I get the time. But also learning as I go here re BareOS and upstream (x2) ways and means. |
|
Ultimate upstream does not account, it seems, for such separation (artificial in some cases I think) as is attempted in the container authors approach. But they (container author) are 7 years ahead of us on this one! |
|
@FroggyFlox When trying to add a further rocknet that allows name resolution between the File service (local client) container and the Storage service: I get the following prior suspected limitation regarding unique
What we need here is the following addition: So that the communication initiated/directed by the Director service between the local File service and Storage service can name resolve. They can't see each other currently. And the Self-test and Catalog backup tasks are pre-configured to expect this interoperability. The problem here I think is the artificial seperation into too many container of what ultimate upstream (BareOS themselves) considers as on the same machine. Do you see a simple fix here: or are we doomed to have to eternally support our own docker images for BareOS: a project I'm super keen to represent within the Rock-ons we offer. Another example of this artificial seperation is how the php is contained in it's own dedicated container: forcing us to share mounts (with differing internal mount points) to the web-ui that uses the php! |
|
That constraint error is curious... I thought I used a unique source + target constraint and not just a source constraint... Will have to look into that further. A temporary solution I see: given you already create this docker network and you know its name, you could add it as an option to the docker run command of that container. See https://docs.docker.com/engine/containers/run/#container-networking Would that help what you're trying to do? Sorry I'm unable to properly look at it now. |
|
Considering that the container link option for reference: https://docs.docker.com/engine/network/links/ |
|
@Hooverdan96 the approach here, thus-far, does use @FroggyFlox's rocknets, but all these containers, and the fact that we have the indicated limit (on what is likely the last rocknet requried) and that this approach is some-what distant from the ultimate upstream (BareOS): I'm instead now working on our own containerisation of BareOS: as close as possible to BareOS's own install instructions. And, if all goes well, far easier/simpler to Rock-onify. Hopefully I will have a rough draft ready soon; and I will definitely need some assistance in its later development as both your and Flox are more knowledgeable in container building. Likely this will first appear in my personal GitHub as a dedicated repo. With a later promotion to the org. [EDIT] I'm also keen to have this container, via env vars, be capable of configuring itself (on first instantiation) to use BareOS subscription repos. But if no BareOS credentials are entered (blank env vars) then it will use the unsuported community packages from BareOS. Plans afoot but little to show just yet! |
|
ah, ok, I misinterpreted the container links (since I have not used that label before in a definition file). Sorry for the detour here. For my own education: Do I read that correctly? When I look at the 4.2 Django documentation, this is considered a list of lists... so shouldn't this parameter have (https://docs.djangoproject.com/en/4.2/ref/models/options/#unique-together) It seems in the 2.x version of Django it was a tuple of tuples, and then changed to the list of lists concept (and now they're recommending to work the constraint tag): I see more instances of that in our coding, if my observation is correct. |
|
@Hooverdan96 That may well be a nice find, and may explain @FroggyFlox exclamation (#383 (comment)) on the observed limitation seen here with the rock-nets. I'm heading in another direction currently re this PR, but a minimal multi-container reproducer rock-on with duplicate "source_container" value entries across 2 rock-nets defined via the "container_links" element would be good to open an issue for this current observed limitation. That way we could easily see if this Django 2.1 to 4.2 change is to blame. |
|
I believe, I reproduced the behavior and captured my observations in a new Issue on the rockstor-core repository: #2900 |
|
Update: I am shortly due to resume this effort once I have finished the initial development of a new set of fully updated docker images; intended in this case to share /etc/bareos (to ease config and enable the default config backup job) and that instantiate official community current upstream packages from: With the hope that these same images can similarly, once I or a contributor has worked out how, implement the subscription images offered by Bareos available from: |
|
When looking at the community vs subscription repository add programs add_bareos_repositories_template.sh and add_bareos_repositories.sh, the only difference seems to be the I guess, if both options should be offered in the same Rockon/set of docker containers, then it would require an installation during the spinning up of the Rockon? |
|
@Hooverdan96 Re:
Yes, I noticed that. But currently I'm favouring two different Rock-ons. Messy I know but otherwise it looks to be difficult to do this when running the containers under the upstream preferred user. I'll likely get to this soon and we can see what we have with the non subscription arrangement first. Hopefully we can wing as per the docs I've done to date in my own images. Bit by bit. But yes, I intended from the start to enable a choice between the two. But easier said than done it seems. I've also got to reduce the levels I'm currently creating as I had not realised there is additional overhead when using more steps in the docker image. |
|
Closing this second draft attempt using barcus's docker images as having now learned a lot from their work over the years I think we are better off rolling our own. See my #94 (comment) for more details. Essentially I've had to use way too many hacks to squeeze the specific use case of barcus's docker images to ignore. And as such I am starting over with docker images under our own authorship that can be modified to fit our Rock-on system. But I am also keen that our docker images are also appropriate for general use independent of Rockstor's Rock-on docker wrapper. |
Multi Container BareOS server set Rock-on.
Containing:
Fixes #94
General information on project
This pull request proposes to add a new rock-on for the following project:
Information on docker image/s
Checklist
root.jsonin alphabetical order (for new rock-on only)"description"object lists and links to the docker image used"description"object provides information on the images particulars"website"object links to project's main website