Voor de release van FlowG 1.0 wilde het team integraties toevoegen voor de grote cloudproviders. Omdat het testen tegen live-omgevingen duur is en complex is binnen CI/CD-pipelines, is er gekozen voor lokale cloud-emulators via floci.
De ervaringen per provider waren als volgt:
- AWS: Met floci was de implementatie van CloudWatch zeer eenvoudig via Docker en de officiële AWS CLI.
- Google Cloud: Na diverse mislukte pogingen met andere tools bleek
floci-gcp een eenvoudige en werkende oplossing voor Cloud Logging.
- Microsoft Azure: Dit bleek de grootste uitdaging. Vanwege strikte HTTPS-vereisten en complexe authenticatie-implementaties was
floci-az noodzakelijk, al blijft de ervaring met Azure minder soepel dan met de andere providers.
De auteur concludeert dat hoewel floci ideaal is voor functioneel testen en CI/CD, handmatige verificatie op de werkelijke infrastructuur nog steeds essentieel is, omdat de emulators geen echte authenticatie-tokens valideren.
Gebruik van lokale cloud-emulators
Met de naderende release van FlowG 1.0 heeft ons team gekeken naar wat gebruikers zouden kunnen missen in onze eerste stabiele versie. Hoewel we al acht algemene forwarders hebben, misten we directe integraties met de grote cloudproviders.
De drie grootste cloudproviders hebben hun eigen oplossingen voor het verzamelen en beheren van logs, met propriëtaire implementaties en aangepaste bibliotheken. Hoewel het gebruik van de bibliotheken over het algemeen eenvoudig is, bleek het testen ervan veel moeilijker. Het testen van software-integraties met grote cloudproviders vereist meestal accounts voor elke service, samen met aanzienlijke kosten als ze deel uitmaken van een CI/CD-pipeline die regelmatig wordt uitgevoerd om te garanderen dat er geen breaking changes in het project worden geïntroduceerd.
Het gebruik van floci voor AWS CloudWatch-emulatie
De eerste integratie die we hebben geïmplementeerd was voor de AWS CloudWatch-service. Tijdens het zoeken naar lokale cloud-emulators viel floci op als de meest professionele oplossing.
Het gebruik van floci kon niet eenvoudiger zijn. Alles wat nodig was, was één Docker-commando, en je hebt een lokale versie van vele AWS-services:
docker run -p 4566:4566 floci/floci:latest
Het configureren van de go aws-sdk-go-v2 bibliotheek om een lokaal eindpunt te gebruiken is nog eenvoudiger: geef gewoon een eenvoudige url-string mee aan de configuratiestructuur en je gebruikt een lokale floci-instantie.
We konden log-groepen en streams maken met de officiële AWS CLI-tool of Python-bibliotheek en zagen in geen tijd dat de doorgestuurde logs naar behoren werkten:
export AWS_ENDPOINT_URL=http://localhost:4566
export AWS_DEFAULT_REGION=us-east-1
export AWS_ACCESS_KEY_ID=test
export AWS_SECRET_ACCESS_KEY=test
aws logs create-log-group --log-group-name flowg
aws logs create-log-stream --log-group-name flowg --log-stream-name logs
Zoeken naar een Google Cloud Logging-emulator
Vol hoop na het AWS-succesverhaal verwachtten we dat het toevoegen van Google Cloud Logging net zo eenvoudig zou zijn. We vonden na wat onderzoek een paar oplossingen die erg leken op wat floci voor AWS bood, maar na het uitproberen van ze allemaal bleek geen enkele van de oplossingen daadwerkelijk te werken. Sommige hadden zelfs geen functionele downloadlinks, of de verstrekte instructies waren volledig onjuist.
Terwijl we andere oplossingen onderzochten, werkte het floci-team stilletjes aan floci-gcp en voegde functies toe die we eerder misten. Toen we beseften dat we opnieuw floci konden gebruiken, werden we opnieuw begroet door de eenvoud en het gebruiksgemak. Hoewel de bibliotheek van Google wat configuratie vereiste om onveilige lokale verbindingen toe te staan, was er geen creatie van streams of groepen nodig en was het net zo eenvoudig te gebruiken als AWS.
De eindbaas: Microsoft Azure
Omdat andere cloudproviders zo eenvoudig waren en we beseften dat floci-az Azure Monitor al ondersteunde, dachten we dat dit routine zou zijn en in geen tijd gedaan zou zijn. Maar Microsoft vindt altijd een manier om dingen te compliceren.
Al onze vorige lokale cloudservers gebruikten HTTP, aangezien er geen authenticatie is en ze alleen worden gebruikt voor CI/CD, niet voor werkelijke implementaties. AWS werkt zonder wijzigingen, Google vereist expliciete configuratie voor HTTP, en dat doet Microsoft ook, totdat je het daadwerkelijk probeert te gebruiken.
Microsoft staat ons wel toe om de InsecureAllowCredentialWithHTTP vlag in te stellen, maar na wat debugging bleek dat de vlag nooit werd gelezen. Gelukkig hielp floci-az ons hier ook mee, met de optie om de server via HTTPS te draaien met de FLOCIAZTLS_ENABLED omgevingsvariabele.
Microsoft vereiste ook dat we een aangepaste authenticatietoken-implementatie maakten als we de systeembrede configuratie niet wilden gebruiken, en we moesten twee verschillende client-bibliotheken gebruiken om de workspace, workgroup en DCR te maken die nodig waren om de logs te verzenden. Tenzij je infrastructuur al zwaar afhankelijk is van Microsoft Azure, zou ik het niet aanbevelen om het voor je projecten te gebruiken.
Authenticatie
Het grootste voordeel van het gebruik van floci is ook het grootste zwakpunt. Floci vereist geen authenticatie en werkt met elke willekeurige string in plaats van een beveiligde token.
Dit is geweldig voor het testen van functionaliteit en voor gebruik binnen een CI/CD-pipeline, maar het geeft ons niet de zekerheid dat onze integratie werkt met de werkelijke infrastructuur van de provider. Daarom moeten we aan het einde van de rit elke cloudprovider nog steeds minstens één keer handmatig proberen en controleren of onze authenticatie in de echte wereld daadwerkelijk werkt.
Hoewel floci geweldig is en ons veel heeft geholpen op deze reis, moet je sommige dingen soms zelf doen.
Gebruik van lokale cloud-emulators
Met de naderende release van FlowG 1.0 heeft ons team gekeken naar wat gebruikers zouden kunnen missen in onze eerste stabiele versie. Hoewel we al acht algemene forwarders hebben, misten we directe integraties met de grote cloudproviders.
De drie grootste cloudproviders hebben hun eigen oplossingen voor het verzamelen en beheren van logs, met propriëtaire implementaties en aangepaste bibliotheken. Hoewel het gebruik van de bibliotheken over het algemeen eenvoudig is, bleek het testen ervan veel moeilijker. Het testen van software-integraties met grote cloudproviders vereist meestal accounts voor elke service, samen met aanzienlijke kosten als ze deel uitmaken van een CI/CD-pipeline die regelmatig wordt uitgevoerd om te garanderen dat er geen breaking changes in het project worden geïntroduceerd.
Het gebruik van floci voor AWS CloudWatch-emulatie
De eerste integratie die we hebben geïmplementeerd was voor de AWS CloudWatch-service. Tijdens het zoeken naar lokale cloud-emulators viel floci op als de meest professionele oplossing.
Het gebruik van floci kon niet eenvoudiger zijn. Alles wat nodig was, was één Docker-commando, en je hebt een lokale versie van vele AWS-services:
docker run -p 4566:4566 floci/floci:latest
Het configureren van de go aws-sdk-go-v2 bibliotheek om een lokaal eindpunt te gebruiken is nog eenvoudiger: geef gewoon een eenvoudige url-string mee aan de configuratiestructuur en je gebruikt een lokale floci-instantie.
We konden log-groepen en streams maken met de officiële AWS CLI-tool of Python-bibliotheek en zagen in geen tijd dat de doorgestuurde logs naar behoren werkten:
export AWS_ENDPOINT_URL=http://localhost:4566
export AWS_DEFAULT_REGION=us-east-1
export AWS_ACCESS_KEY_ID=test
export AWS_SECRET_ACCESS_KEY=test
aws logs create-log-group --log-group-name flowg
aws logs create-log-stream --log-group-name flowg --log-stream-name logs
Zoeken naar een Google Cloud Logging-emulator
Vol hoop na het AWS-succesverhaal verwachtten we dat het toevoegen van Google Cloud Logging net zo eenvoudig zou zijn. We vonden na wat onderzoek een paar oplossingen die erg leken op wat floci voor AWS bood, maar na het uitproberen van ze allemaal bleek geen enkele van de oplossingen daadwerkelijk te werken. Sommige hadden zelfs geen functionele downloadlinks, of de verstrekte instructies waren volledig onjuist.
Terwijl we andere oplossingen onderzochten, werkte het floci-team stilletjes aan floci-gcp en voegde functies toe die we eerder misten. Toen we beseften dat we opnieuw floci konden gebruiken, werden we opnieuw begroet door de eenvoud en het gebruiksgemak. Hoewel de bibliotheek van Google wat configuratie vereiste om onveilige lokale verbindingen toe te staan, was er geen creatie van streams of groepen nodig en was het net zo eenvoudig te gebruiken als AWS.
De eindbaas: Microsoft Azure
Omdat andere cloudproviders zo eenvoudig waren en we beseften dat floci-az Azure Monitor al ondersteunde, dachten we dat dit routine zou zijn en in geen tijd gedaan zou zijn. Maar Microsoft vindt altijd een manier om dingen te compliceren.
Al onze vorige lokale cloudservers gebruikten HTTP, aangezien er geen authenticatie is en ze alleen worden gebruikt voor CI/CD, niet voor werkelijke implementaties. AWS werkt zonder wijzigingen, Google vereist expliciete configuratie voor HTTP, en dat doet Microsoft ook, totdat je het daadwerkelijk probeert te gebruiken.
Microsoft staat ons wel toe om de InsecureAllowCredentialWithHTTP vlag in te stellen, maar na wat debugging bleek dat de vlag nooit werd gelezen. Gelukkig hielp floci-az ons hier ook mee, met de optie om de server via HTTPS te draaien met de FLOCIAZTLS_ENABLED omgevingsvariabele.
Microsoft vereiste ook dat we een aangepaste authenticatietoken-implementatie maakten als we de systeembrede configuratie niet wilden gebruiken, en we moesten twee verschillende client-bibliotheken gebruiken om de workspace, workgroup en DCR te maken die nodig waren om de logs te verzenden. Tenzij je infrastructuur al zwaar afhankelijk is van Microsoft Azure, zou ik het niet aanbevelen om het voor je projecten te gebruiken.
Authenticatie
Het grootste voordeel van het gebruik van floci is ook het grootste zwakpunt. Floci vereist geen authenticatie en werkt met elke willekeurige string in plaats van een beveiligde token.
Dit is geweldig voor het testen van functionaliteit en voor gebruik binnen een CI/CD-pipeline, maar het geeft ons niet de zekerheid dat onze integratie werkt met de werkelijke infrastructuur van de provider. Daarom moeten we aan het einde van de rit elke cloudprovider nog steeds minstens één keer handmatig proberen en controleren of onze authenticatie in de echte wereld daadwerkelijk werkt.
Hoewel floci geweldig is en ons veel heeft geholpen op deze reis, moet je sommige dingen soms zelf doen.
Groetjes,