Collect versions and service information in docker/defaults/main.yml #125
No reviewers
Labels
No labels
Blocked
Existing Service
Infrastructure Issue
Refactor
Security Hardening
Security Issue
Service Idea
Service Removal
Upgrade service
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: data.coop/ansible#125
Loading…
Reference in a new issue
No description provided.
Delete branch "unify_configurations"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Idéen her er at samle metadata om services i docker/default/main.yml.
Lige nu er det kun "version" der er trukket ud fra de enkelte service filer, men planen er også at inkludere beskrivelser, "vores badges", evt. health check endpoint, etc.
Målet er at når der pushes til ansible repoet at der bliver bygget et docker image der bliver deployet på services.data.coop med en oversigt over services, deres version, status (hvis servicen har noget det ligner et health endpoint) og hvilke af "vores badges" der gælder for dem. Dette gør at vi kan præsentere vores services på en måde der svarer til hvad der er deployet (eller i hvert fald skubbet til ansible).
God idé at gøre opmærksom på det gældende badge! Evt. med direkte link til manifestet i
website
repo. P.t. er det inew
branch, men det bliver flyttet.https://git.data.coop/data.coop/website/src/branch/new/content/services
4f7eab9d8d
to6708653c94
@benjaoming Mit mål er at gøre "services" siden på websitet overflødigt - eller måske endda bare gøre det til en iframe der inkluderer services.data.coop
Netop fordi vi har ansible som "single source of truth" og vi kan undgå dobbeltarbejde.
Bare kommunikationen på hjemmesiden er første prio :) men ja, hvis det er yaml eller JSON kan vi nemt importere det via Hugo. Hugo kan faktisk kalde APIer build-time. Vi kan også importere et repo build time og læse YAMLen.
Måske værd at kigge på data.coop/dokumenter#19 til ansible repoet også :) jeg har ikke kigget på hvordan vi inkluderer vedtægter og aup endnu.
Jeg tror jeg er uenig i at kommunikationen af hvilke services vi har og deres status er nødvendig at have på hjemmesiden - jeg synes at et link er nok, hvis det betyder at vi kan lave en bedre og mere overskuelig oversigt over vores services.
Min plan er at bygge et site som er seperat fra hjemmesiden - først og fremmest for at vise status over vores services. På sigt håber jeg at det kan blive erstatningen for hjemmesidens "tjenester" side.
Hvis det skal være rigtig vildt så hoster vi
services|status.data.coop
på en helt anden maskine end den hvor vi kører alt andet fra, så den er tilgængelig selvom at serveren(e) er nede.Jeg kan især godt lide at vi har versionsnumre stående samlet, da det vil give et bedre overblik ift. når vi skal opgradere services (#123).
@ -19,1 +18,4 @@
ALLOWED_SENDER_DOMAINS: "{{ allowed_sender_domains|join(' ') }}"
HOSTNAME: "smtp.data.coop" # the name the smtp server will identify itself as
vars:
allowed_sender_domains:
Jeg synes det her bør flyttes tilbage til
defaults/main.yml
, så vi har alle vars samlet ét sted.Det er fordi det ikke kan defineres i selve services dictionary'en da der refereres til services dictionary'en før den en færdig defineret. Jeg har muligvis en anden løsning coming up.
Aaah, det giver selvfølgelig mening.
@ -405,3 +405,3 @@
// @type string
//
url: "ldap://{{ ldap.domain }}",
url: "ldap://{{ services.openldap.domain }}",
a6420830e4
@samsapti jeg skal bruge lidt mere info ;)
Vi har ikke thelounge mere, så hele den fil bør fjernes :)
@ -15,2 +16,4 @@
enabled_services:
- nginx_proxy
- postfix
- openldap
Hvis den her er tilbage, hvad er så forskellen på det, og det vi har på
main
? Det her virker meget mere komplekst.d372a6ece6
to55c9a346b1
cfb78eac12
to2603852f1c