How to edit Elastic Beanstalk code without re-uploading application? - amazon-web-services

I am building a web-app using Elastic beanstalk on AWS and was wondering if there was a way that I can edit the source code without having to re-upload a zip of my application every time I want to make an edit.
Thanks!

The Elastic Beanstalk environment is based on EC2 instances. You can connect to your instances using SSH and, inside the instance, download your source code. If you use a non compiled language, like Javascript (Node) or Python you can edit the code directly. If you use Java you will need to upload the source code and compile it. Maybe using the environment JDK.
But keep in mind two details:
You must install your compiled/edited code in the same path used by elastic beanstalk;
If your instance is reinitialized, your changes will be lost, because in this case eb will get a fresh copy of your code based on your last upload.

Related

New Elastic Beanstalk instance not using .htaccess

I'm having a weird issue I've not encountered before: My new Elastic Beanstalk environment is not respecting my .htaccess files. It's odd because I don't recall this ever being a problem before. In fact I have an older EB environment that I set up years ago and it's fine with the game code.
This new environment is 64 bit Amazon Linux 2.
Looking elsewhere there are guides saying you need to edit your /etc/httpd/conf/httpd.conf file, but my EC2 instance doesn't have one. (I also don't have an /etc/apache2 directory.) The closest it has is a /etc/httpd/conf.d/php.conf file.
I don't recall ever having to do this previously, and obviously I'm a bit concerned that my EC2 instance will forget any changes to any .conf files if I have to spawn new instances are created in the future.
How do you get my EB/EC2 instance to implement my .htaccess files?
From v3.0.0 onwards, Amazon changed their Elastic Beanstalk PHP Platforms to use nginx as their server instead of Apache. This is not mentioned anywhere when you're creating your platform, so it can catch you unawares.
If you want to use Apache, you need to select a platform version of v2.x.x.
See the full history of Elastic Beanstalk PHP platforms for specific details.
An update to the other answer, you can now change the server in versions 3+ to apache by updating the proxy server in the configuration.

Deploy only changed files on AWS Elastic Beanstalk website

I have successfully deployed my website on AWS Elastic Beanstalk. Now I want to change the code in one of my file.
If I do eb deploy, it will completely deploy a new version of my code which I don't want. I already have an updated DB on Elastic Beanstalk. If I deploy the whole code again, it will overwrite my DB file.
How can I deploy the changed file only successfully?
This may not be the answer you're looking for, but I would highly recommend deleting this file from your code repository. Hopefully you're using a version control system like Git; if you want to keep the original file for historical purposes, I would create an entirely different repository and put it in there.
Why? Even if you did come up with a solution to only deploy changed files...would you really want to trust it? If there's any problem with the solution you came up with, you would entirely erase/overwrite your production database. Not good.
In addition, if you want to build a really robust system to entirely create your app from scratch in AWS, take a look at Cloud Formation. It takes some learning and work, but you can build a script -- and maintain it in version control -- that will scaffold your entire cloud infrastructure.

Limitations of Immutable Deployments on AWS/EB

I am trying to understand the disadvantages of immutable deployments on AWS/Elastic Beanstalk. The docs say this:
You can't perform an immutable update in concert with resource configuration changes. For example, you can't change settings that require instance replacement while also updating other settings, or perform an immutable deployment with configuration files that change configuration settings or additional resources in your source code. If you attempt to change resource settings (for example, load balancer settings) and concurrently perform an immutable update, Elastic Beanstalk returns an error.
(Source: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environmentmgmt-updates-immutable.html)
However, I am unable to come up with a practical scenario that would fail. I use CloudFormation templates for all of the configuration. Can the above be interpreted that I cannot deploy CloudFormation changes as well as changes to the application (.jar) at the same time?
I would be very thankful for clarification.
Take this with a grain of salt because it's just a guess based on reading the docs; I think basic support is $40/month, would be a good question to ask them to know for sure.
Can the above be interpreted that I cannot deploy CloudFormation changes as well as changes to the application (.jar) at the same time
I'm assuming you deploy your application .jar using a different process than your CloudFormation template. Meaning when you deploy source code you don't use CloudFormation, you maybe use a CI/CD tool e.g. Codeship. And when you make a change to your CloudFormation template, you log in to AWS Console and update the the template there (or use the AWS CLI tool).
Changing both at the same time would, I think, fall under what they're saying here. Don't do it for obvious reasons; you wouldn't want CloudFormation trying to make changes to an ec2 instance at the same time that EB is shutting down that instance and starting a new one. But a more common example would be I think if you happen to use .ebextensions for some configuration settings.
.ebextensions are a way to configure some things in EB that CloudFormation can't really do or easily do. They are config files that get deployed with your source code in a folder named /.ebextensions at the root of your project. An example is changing some specific linux settings https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html
You wouldn't want to make a change to your application code and an .ebextension at the same time. This is just my guess at reading the docs, you could test this out pretty easily.

Jenkins/Hudson call script on AWS EC2 Instance

Today, on my work, when we need to deploy a Play! Framework (1.2.7) app in our EC2 Instance (AWS), we need to access the server and call a script that download all the source code, precompile the source code, start Play! Framework and restart nginx (everything in one script - .sh).
This process work fine today, but in emergency cases it's very slowly because we need to access de EC2 Instance (with key pair) and depending on the location the internet is slowly.
I want to know if is possible to use Hudson/Jenkins to just call this script on my EC2 Instances. I know that Hudson/Jenkins have a lot of functionality (test, build, etc.) but for now I just want to deploy my app (call the script from ec2-instance).
If anyone knows another tool that help, I will be very grateful.
Thanks.
You can use/build SBT plugins to run the remote command, or simply exec the local ssh with the command, but that can get quite hard to debug.
If you can build your instance to bootstrap itself from scratch, for example with a UserData script, then all you need to do is terminate your old instance and start a new one, and that is much easier to automate.

How does ElasticBeanStalk deploy your application version to instances?

I am currently using AWS ElasticBeanStalk and I was curious as to how (as in internally) it knows that when you fire up an instance (or it automatically does with scaling), to unpack the zip I uploaded as a version? Is there some enviroment setting that looks up my zip in my S3 bucket and then unpacks automatically for every instance running in that environment?
If so, could this be used to automate a task such as run an SQL query on boot-up (instance deployment) too? Are these automated tasks changeable or viewable at all?
Thanks
I don't know how beanstalk knows which version to download and unpack, but running a task on start-up is trivial. Check out cloud-init, a tool written by Ubuntu that's now packaged in Amazon Linux. It allows you to pass arbitrary shell scripts into the UserData section of the instance configuration, and those shell scripts will run on startup.
It's a great way to bootstrap instances on startup, which avoids the soul-sucking misery of managing AMIs.
A quick (possibly non-applicable) warning: If you're running a SQL query on a database that lives on the beanstalk AMI, you're pretty much guaranteed to lose your database at some point. Those machines are designed to be entirely transient. Do not put databases on them. See this answer for more details.
Since your goal seems to be to run custom configuration tasks, the answer is yes, there is a way to do that. You can define custom actions in an .ebextensions file packaged with your app. For example, you can configure a command to run every time a new machine is deployed:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html#linux-commands