As part of the DevOps Masters Program on Simplilearn, had to configure a jenkins pipeline. For the same, even though they do provide a lab environment, I feel at home with AWS and cli. I myself being part of the AWS Community Builders, should normally prefer this approach.
For the particular project, the infrastructure was visualized by me as two AWS::EC2 pre deployed one for Jenkins master node, and the other for java+tomcat to deploy a sample app. The Jenkins would be configured with Cloud Plugin configured to manage EC2 nodes for build and test and finally deploy to the tomcat using remote deployment using war. Making the long story short lets jump straight into the steps. Agree that I completed the Project Run in about a couple of hours and creating such a template and running through aws-sam was purely on academic interest. Download the template file: cf-template-ec2-jenkins-tomcat-ubuntu-bionic.yaml
Mostly these days, I am working with IaC using aws sam cli which gives me a kind of satisfaction – its cumbersome for me to go into the myriad of web gui and continuously clicking. By creating templates and running them from cli has been my choice for too long.
Getting straight into the job, will summarize the initial requirements and the architecture, then move on to additions.
Host a Static Site on S3, deliver it globally through Cloud Front CDN with SSL over HTTPS. Once deployed the Route53 tables should be updated. The deployment should use aws sam cli and IaC.
Though there is not much complication in the architecture, while deploying this during the first pandemic wave, after multiple attempts I found that the cloudfront should be created in specific region such that the SSL certificate can be attached.
Design and architect a highly available, large user base system which is going to be used by the National Highways, the regular employees updating photos of WIP on different stages and when work completed, archive all images after creating a timeline video. WIP sequence should keep the most latest photo thumbnail linked to a project blog page, with a gallery linking to last photo per day. Post-processing of a completed work can take even up to a week giving more importance to the lowest cost possible. The system should be capable of handling hundreds of thousands of high-quality mobile photographs per day. Runtime costs should be as low as possible. For each WIP a minimum of one photograph in six hours is desired.
Solution on AWS (My views):
That is routed to an API Gateway, which triggers a lambda.
Lambda (Node.js) evaluates the signature.
If signature is valid, write email json into s3 bucket and triggers an EC2 spot instance with an EBS Volume attached.
The user-data is injected with startup and delayed startup to pick and post the article from S3 into the WordPress on EBS
Inline images are stripped and uploaded into the media manager, and links are replaced appropriately.
Custom scripts utilizing mirror-website and other cli tools will convert the www.jijutm.com website to a static site
WordPress has S3 support for Media Manager through a plugin.
Downloads are directly uploaded into a download bucket.
Then site is synced to s3 with proper expiry headers
CloudFront is invalidated using the aws cli command.
The services are stopped internally and EBS is unmounted
Finally, the EC2 instance is terminated.
The EBS volume was prepared with the data, html and server configuration files. The spot instance is created from a custom ami which is updated time to time and provided to the lambda through environment variables.
This will run for me since I am the sole author of this blog, and my frequency of posting is very low hardly once in two months. For a high frequently updated portal or blog, this process may even fail totally and if there are more than one author, don’t even think of this. I do agree that there are too many cons, like preview editing, making changes etc are not there. But the most important part for me is this WordPress blog is rock solid, Not Hackable, unless AWS S3 or CloudFront is Hacked. Also page load times are pretty good, though tools like google lighthouse or webpage test are still suggesting more improvements.
Some points are blindly my preference and some other due to the suggested best practices. I do agree that starters, would be better off with setting IAM policies with ‘*’ in the resource field. But when you move things into production it is recommended to use least required permissions. Also, some critical policies were missing from the assume role policy. Another unnecessary activity was the checking of the existence of s3 bucket and attempt to create if not exists, at each repeated execution. Again for this purpose the lambda role needed create bucket permission. All these were over my head, and the outcome is this article.
Well if you need CloudWatch logs to be exported to S3 for whatever reason, this could save your time a lot, though this needs to be run in every different region where you need to deploy the stack. Please excuse me as the whole article expects to have aws-cli and sam-cli pre-installed.
Introducing HoneyCode a new, fully managed low-code/no-code development tool that aims to make it easy for anybody in a company to build their own applications. All of this, of course, is backed by a database in AWS and a web-based, drag-and-drop interface builder.
Developers can build applications for up to 20 users for free. After that, they pay per user and for the storage their applications take up. There is no wait for applications to be approved on play store / app store as the applications are not directly deployed, rather through a pre deployed player ( interpreter ).
Like similar tools, Honeycode provides users with a set of templates for common use cases like to-do list applications, customer trackers, surveys, schedules and inventory management. Traditionally, AWS argues, a lot of businesses have relied on shared spreadsheets to do these things.
Get application performance recommendations and automated code reviews through Amazon CodeGuru, which is a machine learning service. Find the most expensive lines of code that can affect application performance and frustrate you with troubleshooting. The service gives you best recommendations to fix or write better code.
Powered by machine learning, best practices, and hard-learned lessons across millions of code reviews and thousands of applications profiled on open source projects and internally at Amazon, CodeGuru is ready to face any challenge. Find and fix code issues such as resource leaks, potential concurrency race conditions, and wasted CPU cycles, using CodeGuru. Also with moderate, on-demand pricing, it is affordable enough to use for almost all code review and application one might need. Java applications are currently supported by CodeGuru, with support for more languages in the anvil. Catch and resolve problems earlier and with better efficency, with CodeGuru such that you can build and run better software.
For almost over the last decade ( since 2009 ), I was never worried about the EBS performance indexes. Used to create a single volume and attached to an instance as and when required. Today just for wandering, and to entertain myself, did a couple of tests. Thanks to aws-cli without which this could have taken more than what it would.
Straight into what I found in a short summary. Note that the values are Bps.
Performance across different combination of EBS Volumes
PodCasting – on AWS can be damn cheap while being ready for a bigbillion hit…
Amazon Lambda ( S3 Events [and @ Edge ( if not authenticating from Cognito) ] )
Amazon Route 53
Amazon Cognito ( optional if social login is required )
S3 stores raw files in one bucket, and trigers lambda to do the transcoding, if mobile from any format to mp3. Meta information should be uploaded to same bucket as flat file. Also multiple quality files will be generated. Interface will upload meta.json and pod.raw files to S3 bucket.