In dit artikel kijken we naar de profielen van de WSO2 API Manager. Waar zijn deze profielen voor bedoeld en hoe werken ze? Je leert hoe je een profiel optimaliseert als onderdeel van een Distributed Distribution van de API Manager.
Carbon Core
WSO2 producten zijn voor het grootste deel gebouwd op de Carbon Core. Carbon Core is een set van bibliotheken die gebruikt wordt door (bijna) alle producten van WSO2. Het biedt een reeks aan functies die alle producten gemeenschappelijk hebben, zoals clustermogelijkheden, gebruikersbeheer, maar ook bundelmanagement via de Management UI. Dit zijn allemaal onderdelen van de Core. Daarnaast zijn er ook een aantal functionele componenten, waardoor de verschillende producten zoals de Enterprise Integrator, API Manager, Identity Server en de Streaming Processor hun unieke eigenschappen krijgen.
Verschillend maar toch hetzelfde
De meeste van deze componenten zijn jars die op Java gebaseerd zijn. En hoewel componenten hergebruikt worden, zijn de producten niet allemaal hetzelfde. Wat ik daarmee bedoel is dat ze niet hetzelfde zijn vanuit een functioneel perspectief, omdat de Identity Server en de API Manager natuurlijk verschillende type producten zijn, wat ook weer geldt voor de Enterprise Integrator.
Aan de andere kant kun je ook beredeneren dat de producten meer overeenkomsten hebben dan je zou denken, vooral als je het hebt over de API Manager en de Enterprise Integrator. Daardoor is er ook meer samenwerking tussen de twee dan je in eerste instantie zou denken. De API Manager bevat bijvoorbeeld een deel van de key manager die ook in de Identity Server zit. De API Manager en de Enterprise Integrator gebruiken overigens ook dezelfde berichtverwerking (Synapse).
De Enterprise Integrator is in feite een monoliet. Het is een enorm blok aan functies die op zijn eigen JVM start, waarbij de mogelijkheid om een setup met andere functionaliteiten te hebben in andere JVM zo goed als uitgesloten wordt. Voor de volledigheid, de Enterprise Integrator wordt beschouwd als een op zich staand product en dat geldt net zo goed voor de Message Broker en de Business Process Server. Deze drie runnen namelijk altijd op hun eigen JVM.
Wat bedoel is als ik zeg: “een product is monolitisch van aard”? Dit houdt in dat de Enterprise Integrator, en ook de Micro Integrator, als één blok geïnstalleerd worden. De API Manager heeft echter, ongeacht het gebruikt van vergelijkbare componenten, een setup die gedistribueerde deployment (Distributed Deployment) genoemd wordt.
De WSO2 API Manager runnen
Als je het WSO2 API Manager zip-bestand downloadt en runt, dan krijg je in feite één JVM waarin alle vijf de componenten van de API Manager in zitten: Publisher, Devportal, Key Manager, Traffic Manager en Gateway.
Je kunt daarom een gedistribueerde setup voor gedistribueerde deployment doen, waarbij al deze onderdelen op zichzelf in hun eigen JMV-omgevingen kunnen runnen. En één van de manieren waarop je dat kunt is door ze te starten met een zogeheten profiel.
Wat is een profiel?
Een profiel is een gedefinieerde configuratie die alleen de OSGi bundels laadt die nodig zijn om specifieke functies uit te kunnen voeren, bijvoorbeeld als Key Manager. Dit betekent dat de bundels die niet noodzakelijk zijn voor de specifieke functies van dit component, bijvoorbeeld de SYNAPSE configuratie, in dit geval niet geladen worden. Het gevolg hiervan is uiteraard dat er minder geheugen vereist is, omdat we niet alle jar-bestanden gebruiken, maar slechts de benodigde. Daar kan een voordeel in zitten.
Maar hoe kunnen we bekijken wat er in die profielen zit?
Dat gaan we nu ontdekken. Hoe weten we welk soort profielen er beschikbaar zijn voor een bepaald product? Dat is relatief eenvoudig. Je neemt het gewenste product en start het, bijvoorbeeld in een terminal sessie op Linux of met Windows, waar de functie ook beschikbaar is.
API Manager installeren
Ik ga ervan uit dat je Java (Java 8, of Java 11, OpenJDK of Oracle) geïnstalleerd hebt en dat je JAVA_HOME ingesteld hebt. Je hebt nu alle hordes genomen om de setup uit te voeren waarmee je de API Manager kunt runnen. Als je deze nog niet hebt geïnstalleerd, lees dan deze blog over de installatie van WSO2 producten.
Laten we de API Manager opstarten door een out-of-the-box versie op de desktop te unzippen met de vereisten die ik zojuist beschreef. Je kunt de API Manager in feite starten met het ‘shell’ of ‘batch’ script en dan runt het.
In ons geval gaan we nog een parameter aan de API Manager toevoegen. Dat is de parameter: -DosgiConsole. Zoals je in hier in de schermafbeelding kunt zien, voeg je gewoon een spatie toe en daarna de extra parameter.
Wat er dan gebeurt, is dat je een bericht in de console te zien krijgt. Wanneer het systeem start, start ook de OSGi-console en dat is normaliter de interface voor de interne functies van de API Manager.
Dit houdt in dat je via de OSGI-console de geladen bundels, instellingen en dergelijke kunt bekijken. Je kunt hiermee bundels verversen en je kunt zien wat er in een bundel zit, tot Java classes aan toe, enz. Over het algemeen zijn er ruim 20 pagina’s aan ‘help commands’ die je alles kunnen laten zien wat je maar zou willen weten tot op een diep technisch niveau.
De OSGI-console geeft je ook de mogelijkheid om commando’s in te typen. Je zult moeten wachten tot het volledig uitgevoerd is, anders worden de logberichten dwars door de dingen die je aan het typen bent geplaatst. Wat je in de terminal kunt doen als het stopt, dus als je de Management UI URL ziet, is op Enter drukken en dan komt er een cursor tevoorschijn en kun je ‘provlp’ intypen, waardoor een ‘Enter’ toegestaan wordt.
Zo krijg je de profielen te zien die er op dit moment in het product zitten. En zoals je kunt zien, zijn er een aantal specifieke profielen die bij deze operatie horen. We zien bijvoorbeeld de API gateway als een worker node, het Devportal, de Publisher, de Traffic Manager en de Key Manager. Er is natuurlijk ook een Default Profile, omdat het Default Profile gebruikt wordt als er geen profiel als parameter wordt opgegeven. Door een profielnaam toe te voegen aan de provlp commando zullen de afzonderlijke jar-bestanden getoond worden (slechts een klein aantal wordt getoond).
We weten dat er een specifieke setup in een profiel zit. Bovendien kunnen we ook een kijkje nemen naar de [APIM-HOME]/repository/components map waar de mappen voor deze profielen in staan.
Voor dit profiel staan er ongeveer 550 afzonderlijke jar-bestanden in de lijst. Het format heeft de structuur van jar-naam, -versie en -locatie binnen de mapstructuur. Dit overzicht geeft meer informatie dan de OSGI-console. Maar de OSGI-console heeft daarentegen veel meer extra mogelijke commando’s om met profielen te werken.
De optimalisatie van een profiel
Maar een gedistribueerde deployment is meer dan een het inschakelen van een profiel. Er is daadwerkelijke een configuratie om de gedistribueerde deployment in te stellen (hoewel dit te ver gaat om hier te bespreken) en eerst is er nog profieloptimalisatie. We gaan hiervoor een aantal sub-onderdelen verwijderen of in commentaar veranderen. Voor de Publisher is dat bijvoorbeeld de JMS-connectie, WS transports en een aantal andere dingen. Gelukkig hoef je dat niet met de hand te doen.
Een profiel instellen
We kunnen een script gebruiken om deze veranderingen door te voeren. Als we dit script uitvoeren, krijgen we een vraag over de verwijdering of wijziging van een groot aantal bestanden. Zoals je kunt zien worden er ongeveer 1800 bestanden verwijderd uit de setup. Het script is een echt script en geen uitvoerende Java klasse. Het kan dus makkelijk gecontroleerd worden. Dit zul je moeten doen voor alle profielen. Treesize is een geweldige tool voor Windows om een overzicht te krijgen van waar de veranderingen zijn.
Dit is voor de update:
En zo ziet het er na de update uit:
Je kunt als alternatief ook bij het initiële opstarten optimaliseren. In dat geval gebruik je het volgende commando:
wso2server.bat –optimize -Dprofile=api-publisher
Ook dit commando zal voor alle bestanden uitgevoerd moeten worden.
Aangepaste profielen en Distributed Deployment
Met deze geoptimaliseerde instellingen ben je er klaar voor om een gedistribueerde deployment uit te voeren. Zoals eerder gezegd, gaat dit te ver om hier te bespreken, omdat daar flink wat extra werk voor nodig is.
Er is ook een mogelijkheid om je eigen aangepaste profiel te creëren door een a specifieke setup te combineren, bijvoorbeeld Devportal en Publisher in één. Het zal je niet verbazen dat ook dat te ver gaat om hier uit te leggen, vooral omdat het een gevorderd onderwerp is en deze blog twee keer zo lang zou maken.
Conclusion
Als je een deployment van de API Manager in een gedistribueerde deployment wil, dan geeft de setup met een profiel je de mogelijkheid om overbodige onderdelen automatisch te verwijderen of in het commentaar te plaatsen. Vanaf dat punt kun je beginnen met de configuratie van de setup van de gedistribueerde deployment. Idealiter gebruik je ook dan een script, zodat je niet iedere configuratie met de hand hoeft te doen.
Helaas hebben we geen aangepaste profielen en gedistribueerde deployment kunnen bespreken. Maar in onze training over de API Manager behandelen we de gedistribueerde deployments en aangepaste profielen wel. (Aangepaste profielen zijn in ontwikkeling.) Dus als deze onderwerpen je interesseren, bekijk dan de planning van onze trainingen.
