A presentation delivered to the Melbourne AWS Meetup on the May 24, 2018 . Discusses the implementation of the new AWS Containers sub-generator, which allows JHipster applications to be deployed on Amazon ECS, leveraging Fargate.
2. ● Started life as an opinionated code generator, for generating Spring
Boot + Angular Web Applications (now React as well):
● Moved into an opinionated development platform to generate,
develop and deploy Microservices:
What is JHipster?
+ =
9. Existing AWS Generator
● Based on Elastic Beanstalk, using the Tomcat as the deployment
option. Everything else had moved to Docker.
● Used the AWS API to deploy, without extensive error handling. If it
fails halfway through…
● Easy to make mistakes with input. Limited validation before execute.
● No clear understanding of what it actually does to your account.
● Not really supported by anyone, and hadn’t been updated in years.
10. Shiny New Toys
● AWS Announced Fargate support in late November 2017.
● What is Fargate?
○ Allows you to run containers without having to manage servers.
○ At the time was only available in us-west-1, with all the other cool kids.
○ On-demand pricing model *
13. Our Goal
● Docker based.
● Leverage AWS Native where possible.
● Turnkey deployment. Similar to the Heroku Generator.
● Avoid analysis paralysis with questions asked.
● Pre-populate with data based on a user’s AWS account. VPC IDs,
Subnets etc…
● Monolith option to start with.
● CloudFormation.
15. Generator Flow Chart
Start, pre-populate data
from Account
Deployment
Questions
More
Questions
?
Retrieve More Data
Inject Spring Cloud
Templates
Deploy?
Compile + Package
Project
Run CF Part #1
Upload Docker
Image to ECR
Generate CF
Run CF Part #2
End, Bezos Profit
Yes
No
Yes
No
17. Yeoman
● JHipster was originally a
yeoman-generator, but is now a
standalone CLI, which uses yeoman
underneath.
● Wanted to align with the existing
codebase as much as possible.
● Getting our head around the Yeoman
context took a while.
● this.async used heavily as some kind of
punishment.
● Understanding the Yeoman runtime
context is important.
18. CloudFormation
● Spinning up the stack is slow (mainly due
to Aurora). Small Aurora instance on
Sunday night took ~8 minutes to spin up.
● Went with a nested-stack approach,
allowing you to deploy multiple
applications at the same time.
● Split the script into two phases, using
Conditions to toggle the service on and
off.
● CloudFormation files defined in EJS.
19. Fargate Costs $$$$?
● Current pricing model primarily targeted at infrequent (ie, not
continuously running) processes.
● Price per vCPU is $0.00001406 per second ($0.0506 per hour) and
per GB memory is $0.00000353 per second ($0.0127 per hour).
● Assuming that 1 vCPU is the same between Fargate and EC2...
● Fargate Pricing: 1 vCPU + 2GB running all month
○ ($0.0506 * 24 * 31) + ($0.0127 * 24 * 31) = 37.6464 + 9.4488 = $47.0952 a
month
● EC2 Pricing
○ ($0.023 * 24 * 31) = $17.112 a month.
● However if you’re allergic to any kind of system management, that
might look like a bargain.
20. Secure Access to Aurora Part 1
● Password for database access. Can use IAM with Aurora with MySQL
compatibility, but doesn't work with Aurora with Postgres.
● General things you shouldn’t do:
○ Bake them into the CloudFormation file.
○ Expose via Environment Variables in the Task Definition.
● Decided on AWS Systems Manager (SSM) SecureString to store the
password. Unfortunately not directly supported by CloudFormation.
● Our Solution: Asks for the database password once, stores it in SSM.
When needed for subsequent executions of the CloudFormation
script, it reads it back in.
21. Secure Access to Aurora Part 2
● How to get the password into Spring?
● Spring Cloud:
○ Has an AWS Spring Cloud Connector, but doesn’t support SSM.
○ However, does introduce a BootStrap Application Context.
● Wires in a new PropertySourceLocator object which retrieves any
properties set via AWSSimpleSystemsManagement. Makes the
properties available via existing Spring PropertySource mechanism.
● From an IAM perspective, the task has a role which allows access to
the SSM Secure String.
22. Fargate != Lambda
● Although you don’t have to worry about servers, AWS does, and you
can see it.
● Startup time for a JHipster task approximately 40 seconds. Seems to
take longer if the cluster is new.
23. Can’t Get Host Address
This doesn’t work by default in a container running in Fargate.
24. Random Tidbits
● Can’t delete an Elastic Container Registry if there are images in it.
● Initially we were going to deploy a VPC as part of the generator.
Decided against that due to complexity. Supports default VPC (for
the lazy), and a basic two-tier model.
● Even with a CLI, it’s still good to show loading behaviour.
29. Things to come...
● Ability to delete the stack from the cli.
● Ability to deploy to EC2 Instances & Fargate.
● Microservice support; waiting on EKS.
○ Existing Kubernetes generator is heavily used, but not as turn-key as I
would like.
● HTTPS support would be great...
30. All the Links
Main Site: http://www.jhipster.tech/
Source Code: https://github.com/jhipster/generator-jhipster
AWS Guide: https://www.jhipster.tech/aws/
CI/CD Talk:
https://gerard.gigliotti.com.au/putting-the-fun-into-function
ing-ci-cd-ae7adb19ea17
