Hieronder een aantal vragen die vaker langskomen.

Het aanmaken van nieuwe projecten is gelimiteerd tot omroep medewerkers, dit is gedaan om omroepen zelf de controle te geven wat er op hun naam gedaan wordt. Externe developers kunnen via de omroepen rechten krijgen op een project. Als een externe ontwikkelaar een nieuw project wil moet dat via de omroep aanvragen.

Ons streven is dat je als ontwikkelaar snel aan de slag kan met OpenShift. Op deze wiki staan belangrijke concepten uitgelegd en staan ook verschillende scenario's beschreven. Doormiddel van de juiste templates hoef je alleen de applicatie-code aan te leveren en eventueel instellingen voor bijvoorbeeld php modules door te voeren. De web-interface maakt je project inzichtelijk en de command-line interface werkt ook op een overzichtelijke manier.

Dat kan inderdaad. Op deze manier kun je de images die je hebt gebouwd in Openshift lokaal debuggen. Log in op de web-interface, klik rechtsboven op je username. En klik op copy login command: , klik vervolgens op “Display Token”. Kopieer het token (oc login –token=<token> –server=https://api.cluster.chp4.io:6443), en plak deze vervolgens in een terminal om in te loggen op de cli.

Voer vervolgens het volgende commando uit, hiermee log je in op de registry van Openshift.

oc registry login https://openshift-image-registry.apps.cluster.chp4.io

Eenmaal ingelogd kun je images naar je lokale docker-omgeving halen via:

docker pull openshift-image-registry.apps.cluster.chp4.io/<project>/<image>

Om er achter te komen wat je nou precies bij project en image moet invullen kun je, als je in het juiste project zit, de details van de images opvragen via:

oc get imagestream
NAME                   DOCKER REPO                                                                   TAGS     UPDATED
alpine                 docker-registry.default.svc:5000/voorbeeldprojectje/alpine                    3.11     6 weeks ago

Vervang docker-registry.default.svc:5000 door openshift-image-registry.apps.cluster.chp4.io, en let ook op wat er bij tag staat. Bijvoorbeeld:

docker pull openshift-image-registry.apps.cluster.chp4.io/voorbeeldprojectje/alpine:3.11

Het is technisch mogelijk om ook images te pushen, maar dat is meestal een slecht idee:

“Using only commits is bad if you lose track of how to rebuild your image. You don't want to be in the state that you can't rebuild the image. This final state is here called the golden image as the image will be your only reference, starting point and ending point at each stage. If you loose it, you'll be in a lot of trouble since you can't rebuild it. The fatal dead end is that one day you'll need to rebuild a new one (because all system lib are obsolete for instance), and you'll have no idea what to install… ending in big loss of time.”

Als je onze templates en die van OpenShift zelf gebruikt, hoeft dat niet. Wij raden ook aan om die zoveel mogelijk te gebruiken.

Allereerst is het belangrijk om te beseffen dat als je een docker pull of docker run uitvoert, je een binary binnenhaalt. Iedereen kan zijn images op docker-hub zetten dus kwaliteit is niet gegarandeerd. Voor wat meer zekerheid hebben we een aantal belangrijke tips:

1. Gebruik bij voorkeur de templates (en dus ook de images) die wij hebben gemaakt.
2. Gebruik bij voorkeur “official images” en images van “verified publishers”.
3. Vermijd images waarvan de volledige dockerfile (en artifacts) niet beschikbaar zijn.
4. De containers moeten “rootless” kunnen werken, dus zonder root-user en zonder root-rechten. Als de dockerfile beschikbaar is kun je, waar nodig, de image aanpassen zodat deze “rootless” kan werken.

Bij official images en “verified publishers” is de documentatie meestal op orde en zijn ook alle docker-files beschikbaar waarmee je zelf de image kan bouwen of aanpassen.

1. Let op of de image goed wordt onderhouden (en dus recent updates heeft gekregen).
2. Kijk of er (goede) documentatie voor te vinden is. Vermijd images zonder beschrijving/documentatie
3. Let bij de dockerfile op de “FROM” statement; dit is een base-image, zie toelichting.

Een base-image vormt de basis waarop een image wordt gebouwd. Dit is vergelijkbaar met een Linux-distributie. Het is een probleem als er gebruik gemaakt wordt van een oude distributie of als dit een volledige distributie is die niet geoptimaliseerd is voor container gebruik. Met (te) grote base-images worden allerlei zaken meegeleverd die niet nodig zijn om de applicatie te draaien. Al die extra dingen kunnen een potentieel security lek bevatten en moeten worden geüpdatet.

Het is mogelijk om op een laptop en/of desktop een developer omgeving te draaien van het Container Platform.
Deze omgeving is vrijwel identiek aan de productie omgeving behalve dat het een aantal toegevoegde features mist.
Bijv. :

• Geen Cloud diensten zoals Web Application Firewall
• Geen verbinding met AWS/Google diensten zoals hun hosted Databases, echter databases in containers zijn wel gewoon beschikbaar
• Geen High Availablility, echter blijft het wel mogelijk om te schalen binnen de developer omgeving zodat interconnectivity hetzelfde blijft.
• Geen Runtime Security Scanning

Meer informatie hierover is hier te vinden

Dat klopt helemaal. Die mailserver is alleen bruikbaar vanuit de appcluster(en andere *cluster) omgeving. Om te kunnen mailen vanaf Openshift/CHP zal je gebruik moeten maken van AWS Simple Email Service (SES). Wij zetten SES voor je aan in het AWS account dat aan je omroep/afdeling is gelinkt. Meer informatie over het aanvragen van AWS SES vind je hier

Uitgaand verkeer vanuit openshift pods naar het internet staat open. Als je een uitgaande connectie initieert (bv een https call of een uitgaande ssh sessie) dan “ziet” de ontvangende kant die binnenkomen vanaf een aantal specifieke IP adressen, de source adressen. Deze hangen in CHP aan de zogeheten NAT routers van de VPC. Daarvan hebben we er 1 per zone, er zijn 3 zones, dus ook 3 IP adressen, te weten:

# CHP5 Test
15.236.249.238
13.39.6.209
35.181.147.23

# CHP5 Prod
18.184.54.251
18.196.232.108
18.194.162.251

Helaas ondersteunt OpenShift nog geen IPv6, dus uitgaande IPv6 connecties zijn nog niet mogelijk.

Stel nou dat je binnen CHP twee projecten hebt die met elkaar praten; code uit project A connect met code in project B. Vanaf welke IP adressen ziet project B nu de connecties binnenkomen?

Het antwoord is: dat hangt er vanaf hoe je de service (in project B) benaderd. Er zijn 2 manieren waarop je een service kan bereiken:

• Intern via <service>.<namespace>.svc.cluster.local: de requests komen van 10.x.x.x adressen
• Extern via de publieke route: de requests komen vanaf bovenstaande 3 IP adressen.

OpenShift heeft een aantal security-maatregelingen aan boord, de officiele documentatie zegt bijvoorbeeld het volgende over:

“OpenShift Container Platform enables organizations to meet security, privacy, compliance, and governance requirements.”

Bron

Het voert helaas te ver om alle beveiligingsmaatregelen hier te behandelen, maar voor het deployen van applicaties kan het handig zijn om te weten wat rootless containers zijn.

Omwille van de veiligheid mogen containers in OpenShift niet als de user root draaien maar moeten hun eigen user hebben. Vandaar de term 'rootless'. Onze templates en die van OpenShift zelf zijn gebouwd om niet als user 'root' te draaien. Rootless betekend bijvoorbeeld ook dat de processen in de container niet op port 80 of andere ports onder 1024 mogen draaien, want daarvoor moet je root-rechten voor hebben. In de praktijk werken je sites en applicaties binnen openshift gewoon wel op port 80 en 443 met http/https want alle connecties lopen via services en routes.

Rootless containers worden steeds meer gemeengoed, op het moment van schrijven is rootless mode ook als experimentele functie beschikbaar voor Docker. Steeds meer containers worden ingericht om rootless te kunnen draaien.

In het nieuwe platform zullen een aantal dingen veranderen wat betreft de kosten. Onze verwachting is dat de kosten voor omroepen wel iets omhoog gaan, echter dit is voornamelijk door de nieuwe Netwerk verkeer kosten. We zullen een aantal categorieën hebben waar de kosten in gaan vallen.

In het nieuwe platform is het niet meer nodig om vooraf capaciteit in te kopen, hierdoor willen we gaan factureren op basis van daadwerkelijke kosten ipv potentiële piek vermogen. Dit houd in dat we willen factureren op CPU en Geheugen verbruik per uur en hierdoor omroepen betere controle krijgen over de kosten per site.

In het begin van het platform zullen we nog de oude facturatie aanhouden zodat wij en de omroepen een beter beeld kunnen krijgen in het daadwerkelijke verbruik en we zullen later per omroep dit omzetten naar facturatie op basis van verbruik.

Zoals nu al voor de meeste omroepen gebeurt zal de facturatie van de storage op basis van verbruik zijn.

In het huidige platform leven we op het NPO netwerk, hier betalen we niet voor verbruikt verkeer maar voor de aansluitingen naar de Internet Exchanges. Vanuit de cloud hebben we helaas niet die optie en wordt hier de traffic op verbruik gefactureerd.

Om de kosten lager te houden bieden we een Static Asset CDN aan op het NPO netwerk. we hebben berekend dat 80~90% van het verkeer van omroep websites statische content is en als een omroep deze vanuit het NPO netwerk kan uitserveren dan zal dit een potentiële besparing van 50% op de netwerkkosten zijn.

De extra afgenomen cloud diensten zullen vrijwel 1-op-1 door gefactureerd worden, hier zal een laag percentage bovenop liggen tbv bijkomstige administratieve kosten hiervan te dekken.

Support van het huidige appcluster wordt langzaam teruggeschroefd. Waar we voorheen 1x per 4 weken software updates deden is dat inmiddels teruggebracht naar 1x per 8 weken. Aanvragen voor nieuwe sites in het appcluster worden niet meer in behandeling genomen. Wèl houden we de software versies in het appcluster op peil. Dat betekent dat zowel minor als major software upgrades gewoon doorgaan. Concreet kan dat inhouden dat we in het appcluster ophouden met het aanbieden van EOL software versies van b.v. php of mariadb en dat de sites die nu nog in het appcluster draaien dus nog wel degelijk onderhouden dienen te blijven worden, zodat ze geschikt zijn om in up-to-date software omgeving te draaien.

Het appcluster zal tot 30 juni 2023 actief blijven.

Let op: de EOL datum van het appcluster is inmiddels meerdere malen opgeschoven. Een gevolg hiervan is dat de onderliggende hardware nu afgeschreven en niet meer in support is. Het is echt de hoogste hoogste tijd om te migreren.