Package: poja
POJA CLIThe Python CLI for maintaining aPOJA stack... or dozens of them!General usageInvoke thePOJA CLIdepending on the use case you want to address, see section below. We recommend prefixing your poja application names withpoja-.Commit changes and push them to Github.Define the Github secrets for deploying into your AWS prod and preprod accounts:PROD_AWS_ACCESS_KEY_ID,PROD_AWS_SECRET_ACCESS_KEY,PREPROD_AWS_ACCESS_KEY_ID, andPREPROD_AWS_SECRET_ACCESS_KEY. If you use the same account for prod and preprod, just give the same values to the prod and preprod variables.Run theCD computeaction. This creates the serverless Spring Boot. The API URL is printed in the Github console.Use casesInstall poja and list all possible parameterspip install poja
python -m poja --helpCreate a completely new projectpython -m poja \
  --app-name=poja-base \
  --package-full-name=com.company.base \
  --region=eu-west-3 \
  --output-dir=folder-to-be-created \

  --with-own-vpc=true \
  --ssm-sg-id=/poja/sg/id \
  --ssm-subnet1-id=/poja/subnet/private1/id \
  --ssm-subnet2-id=/poja/subnet/private2/idThose configurations will be automatically saved inpoja.ymlat the end of the creation.
See section "Use your own VPC" for the--with-own-vpcand--ssm-xxx-idarguments.Upgrade an already existing projectpip install poja --upgrade
python -m poja \
  --app-name=poja-base \
  ...
  --output-dir=folder-already-createdNote the--upgradeand the--output-dir=folder-already-createdflags. The POJA configuration that was used for the previous generation is saved inpoja.yml: it will be updated after the new upgrade.If you want to do an upgrade without re-specifying each parameter (there are more than 20 of them!), then poja conveniently provides the--poja-confparameter.
Just modify the existingpoja.yml(modify mandatorily theversionparameter so that it reflects the newly upgraded version,
modify optionally any other parameter depending on your needs), then:pip install poja --upgrade
cd folder-already-created
python -m poja --poja-conf=poja.yml --output-dir=.Configure your databaseUse--with-database=postgres|non-poja-managed-postgres|sqlite.
In particular,non-poja-managed-postgresis handy if you want to use an already existing Postgres, that you will manually reference through custom Java env vars.If you want POJA to fully manage Postgres: from creation, to operations -- scale-in, scale-out to zero, DDoS protection, regular backups -- to deletion. Then do as follows before running theCD computeaction:Create two entries in SSM that stores the credentials of the database that will be created. The name MUST be as follows:/<?app-name>/<?env>/db/usernameand/<?app-name>/<?env>/db/passwordwhere<?app-name>is any name you want and<?env>is eitherprodorpreprod.Define the Github variablePROD_DB_CLUSTER_TIMEOUTthat sets the prod database cluster scaling down timeout. Note that its value must be between 300 seconds (5 minutes) and 86_400 seconds (1 day). Due to the once-per-day health check action, the (serverless) prod database will always be hot if you set it to one day.Run theCD storageaction. This creates the serverless Postgres. The database URL is printed in the Github console.Use custom/additional Java depsJust provide the argument--custom-java-deps=your-list-of-depswhereyour-list-of-depscontains the dependency lines that are to be added tobuild.gradle.Hereis an example of such a file.Once the generation finishes,your-list-of-depswill be copied at the root path of the genrated directory,
under the namepoja-custom-java-deps.txt.
That file will come handy for future generations based on past generations.Use custom/additional Java env varsSimilar to the Java deps section above, but with--custom-java-env-varsas argument name.Hereis an example of such a file.Use your own VPC- For the moment, you MUST use your own managed VPC for hosting the POJA generated resources.- That is, you MUST use --with-own-vpc=true.- If you want to put POJA resources inside AWS managed network,- contact us and we will tell you what needs to be done.Create first:Two subnets. They MUST be private, and access Internet through a NAT Gateway. Reference their id in SSM under any name you want. If you use public subnets, then some parts of POJA might not work correctly, notably the asynchronous stack and the bucket stack.A security group that allows incoming HTTP traffic, allows all internal traffic, and allows all outcoming traffic. Put its id in SSM under any name you want.WarningRemind that the NAT Gateway associated to the subnets isnotserverless.
Whether your POJA is used or not, the NAT Gateway will generate a fixed lower cost of around $35 per month.
If you host 100 POJA in the same VPC, that makes $0.35 the fixed cost per POJA.Then invoke Poja CLI with the following additional parameters:--with-own=vpc=true \
--ssm-sg-id=/poja/sg/id \
--ssm-subnet1-id=/poja/subnet/private1/id \
--ssm-subnet2-id=/poja/subnet/private2/id