Differences

This shows you the differences between two versions of the page.

--- chp:faq [2019/12/17 11:58] – [Veelgestelde vragen:] matthias
+++ chp:faq [2026/05/27 14:01] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+~~META:
+title = Veelgestelde vragen
+~~
+===== Veelgestelde vragen =====
+Hieronder een aantal vragen die vaker langskomen.
+===== Werken met OpenShift =====
+==== Wat zijn OpenShift projecten en hoe maak ik een project aan? ====
+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.
+==== Wat moet ik als ontwikkelaar allemaal weten van OpenShift om ermee te kunnen werken? ====
+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.
+==== Is het mogelijk van buitenaf te verbinden met de OpenShift image registry?  ====
+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'':
+{{:chp:algemeen:copy-login-command-ocp4.png| }}, 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.
+<code bash>oc registry login https://openshift-image-registry.apps.cluster.chp4.io</code>
+Eenmaal ingelogd kun je images naar je lokale docker-omgeving halen via:
+<code bash>
+docker pull openshift-image-registry.apps.cluster.chp4.io/<project>/<image>
+</code>
+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:
+<code bash>
+oc get imagestream
+NAME                   DOCKER REPO                                                                   TAGS     UPDATED
+alpine                 docker-registry.default.svc:5000/voorbeeldprojectje/alpine                    3.11     6 weeks ago
+</code>
+Vervang ''docker-registry.default.svc:5000'' door ''openshift-image-registry.apps.cluster.chp4.io'', en let ook op wat er bij ''tag'' staat. Bijvoorbeeld:
+<code bash>
+docker pull openshift-image-registry.apps.cluster.chp4.io/voorbeeldprojectje/alpine:3.11
+</code>
+Het is technisch mogelijk om ook images te pushen, maar dat is meestal een slecht idee:
+<fs x-small>//"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."//</fs>
+==== Moet ik als ontwikkelaar ook containers kunnen bouwen en goed zijn met Docker? ====
+Als je onze templates en die van OpenShift zelf gebruikt, hoeft dat niet. Wij raden ook aan om die zoveel mogelijk te gebruiken.
+==== Waar moet ik op letten als ik op zoek ben naar een container op een registry zoals Docker-hub? ====
+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:
+  - Gebruik bij voorkeur de templates (en dus ook de images) die wij hebben gemaakt.
+  - Gebruik bij voorkeur "official images" en images van "verified publishers".
+  - Vermijd images waarvan de volledige dockerfile (en artifacts) niet beschikbaar zijn.
+  - 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.
+  - Let op of de image goed wordt onderhouden (en dus recent updates heeft gekregen).
+  - Kijk of er (goede) documentatie voor te vinden is. Vermijd images zonder beschrijving/documentatie
+  - 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.
+==== Developer omgeving ====
+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 [[chp:developer|hier te vinden]]
+==== We willen graag mail versturen vanuit CHP, maar we kunnen iet meer verbinden met smtp.omroep.nl ====
+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 [[chp:handleiding:aws_ses_aanvragen|hier]]
+===== Network =====
+==== Uitgaand verkeer ====
+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:
+<code>
+# CHP5 Test
+.236.249.238
+.39.6.209
+.181.147.23
+# CHP5 Prod
+.184.54.251
+.196.232.108
+.194.162.251
+</code>
+Helaas ondersteunt OpenShift nog geen IPv6, dus uitgaande IPv6
+connecties zijn nog niet mogelijk.
+==== Source ranges van intern verkeer ====
+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.
+===== Security =====
+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."
+[[https://docs.openshift.com/container-platform/4.2/release_notes/ocp-4-2-release-notes.html|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.
+==== Rootless containers ====
+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
+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
+[[chp:concepten:service|services]] en [[chp:concepten:route|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.
+===== Kosten =====
+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.
+==== Compute ====
+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.
+==== Storage ====
+Zoals nu al voor de meeste omroepen gebeurt zal de facturatie van de
+storage op basis van verbruik zijn.
+==== Netwerk verkeer ====
+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.
+==== Cloud Diensten ====
+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.
+===== Huidige omgeving : Appcluster =====
+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-kalender|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.
+==== End-of-Life Appcluster ====
+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.