I am developing a Lift application deployed on AWS Elastic Beanstalk Tomcat 7 container. My application requires sticky sessions when utilizing the Elastic Load Balancer.
Since my application uses the standard servlet stuff, it serves a JSESSIONID cookie to the client. I would like to configure AWS to use application-controlled session stickiness, where given the name of my cookie, it will keep track of the sessions. However, in Elastic Beanstalk Load Balancer configuration, I only see the ability to configure an AWS-managed cookie. I suppose this will work, but I would rather only serve one cookie and have the stickiness coincide with the sessions consistently with the way we have them configured in our application.
While it appears that we can configure application-controlled session stickiness in the EC2 settings associated with my EB instance, the settings we apply get clobbered any time we make changes in the EB console. This isn't terribly surprising behavior, but I would expect that we would soon forget this behavior and accidentally wipe out our settings.
Does anyone know if it is possible to make the stickiness sticky? :)
Elastic Load Balancer (ELB) supports for application-controlled session stickiness (http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html#enable-sticky-sessions-application). If you want to do this, you can create an .ebextensions scripts to modified the Beanstalk ELB. You can't do this via Beanstalk Web Console.
To configure via .ebextensions, just create a directory named .ebextensions inside your root Beanstalk app and create a file (e.g: 00-load-balancer.config) inside the .ebextensions directory.
The .ebextensions/00-load-balancer.config file could be:
{
"Resources": {
"AWSEBLoadBalancer": {
"Type": "AWS::ElasticLoadBalancing::LoadBalancer",
"Properties": {
"AppCookieStickinessPolicy": [
{
"PolicyName": "HttpSessionStickinessPolicy",
"CookieName": "JSESSIONID"
}
],
"Listeners": [
{
"LoadBalancerPort": 80,
"Protocol": "HTTP",
"InstancePort": 80,
"InstanceProtocol": "HTTP",
"PolicyNames": [
"HttpSessionStickinessPolicy"
]
}
]
}
}
}
}
The config will modify the ELB to listen port 80 and forward it to a certain EC2 instance port 80 based on HttpSessionStickinessPolicy policy. The HttpSessionStickinessPolicy will do application-controlled session stickiness.
Please refer to AWS Elastic Beanstalk (http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-resources.html) and AWS CloudFormation (http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-elb.html) documentation to know more about that.
Related
I was paused an AWS Laravel application from elastic beanstalk by making max instance 0.
And now I want to resume it, and when I made max instance 1, EB create the instance, and I setup the security group to handle ssh port 22 and http port 80, so now the instance is accessible by ssh and all is well, but the environment URL form elastic beanstalk not respond and gives me "This site can’t be reached"
And my security group is
So why I see "This site can't be reached"
Thanks in advance
After some tries I paused and resumed the elastic beanstalk again, and I make rebuild environment, so it working well now
And my security group created automatically by EB to be like this
How do I run two Laravel Docker apps on the same server using one container per app and point to two domains?
Both apps are on the same AWS ec2 server
eg:
container one points to -> one.mydomain.com
container two points to -> two.mydomain.com
I'm new to this.
Is it even possible?
an apache solution would be preferable.
Yes, it is a possible and also different way to that and will suggest to use AWS services.
Using AWS load balancer and Host-based routing and different port publish for each app
Nginx
With AWS approach you need to run your container using ECS.
Create Load balancer
Create cluster
Create service
Attached service to Load balancer and update load balancer routing to Host-based routing app1.example.com, will route to app1
Repeat the above step for app2.
The above is the standard way to deal with the container using AWS.
You can read more about this gentle-introduction-to-how-aws-ecs-works-with-example-tutorial and Run containerized applications in production
With Nginx, you need to manage everything for your self.
Run both containers on EC2
Install Nginx
Update Nginx configuration to route traffic based on DNS
Update DNS Entry and will point to EC2 instance public IP, both DNS, for example, app1.example.com and app2.example.com will point to same EC2 instance but the Nginx will decide which app will serve the request.
server {
server_name app1.example.com;
location / {
proxy_pass http://127.0.0.1:HOSTPORT;
}
}
server {
server_name app2.example.com;
location / {
proxy_pass http://127.0.0.1:HOSTPORT;
}
}
I will recommend these two approaches, Nginx over apache but if you are interested you can check this apache-vhosts
I am using AWS EC2 services with Elastic load balancer. When I try to upload multiple images using plupload, it return error:
The specified file temporary://p1ccn4f5o41dmh1qvmefo1ohv1dq15.tmp could not be copied, because no file by that name exists. Please check that you supplied the correct filename. The website encountered an unexpected error. Please try again later.
I am using 2 EC2 server parallel for my Drupal site and on load AWS create new 2 EC2 instance. so when site is run in full load there are 4 EC2 server is running.
This issues is only comes when 2 or more Ec2 instance are running and tmp folder is working fine with single EC2 server.
How to configure tmp for multiple instance website?
Info from comment by OP:
I am using ELB with strike $_SESSION to maintained the user connection with specific EC2 instance.
I have researched the multiple doc over AWS services and found that we need to maintained the user connection with specific EC2 instance.
A Classic Load Balancer routes each request independently to the registered instance with the smallest load. However, you can use the sticky session feature (also known as session affinity), which enables the load balancer to bind a user's session to a specific instance. This ensures that all requests from the user during the session are sent to the same instance.
Manage Sessions between user request and EC2 instance, we need to Configure Sticky Sessions.
The key to managing sticky sessions is to determine how long your load balancer should consistently route the user's request to the same instance. If your application has its own session cookie, then you can configure Elastic Load Balancing so that the session cookie follows the duration specified by the application's session cookie. If your application does not have its own session cookie, then you can configure Elastic Load Balancing to create a session cookie by specifying your own stickiness duration.
Elastic Load Balancing creates a cookie, named AWSELB, that is used to map the session to the instance.
Use the following create-lb-cookie-stickiness-policy command to create a load balancer-generated cookie stickiness policy with a cookie expiration period of 60 seconds:
aws elb create-lb-cookie-stickiness-policy --load-balancer-name my-loadbalancer --policy-name my-duration-cookie-policy --cookie-expiration-period 60
Use the following set-load-balancer-policies-of-listener command to enable session stickiness for the specified load balancer:
aws elb set-load-balancer-policies-of-listener --load-balancer-name my-loadbalancer --load-balancer-port 443 --policy-names my-duration-cookie-policy
Note
The set-load-balancer-policies-of-listener command replaces the current set of policies associated with the specified load balancer port. Every time you use this command, specify the --policy-names option to list all policies to enable.
(Optional) Use the following describe-load-balancers command to verify that the policy is enabled:
aws elb describe-load-balancers --load-balancer-name my-loadbalancer
The response includes the following information, which shows that the policy is enabled for the listener on the specified port:
{
"LoadBalancerDescriptions": [
{
...
"ListenerDescriptions": [
{
"Listener": {
"InstancePort": 443,
"SSLCertificateId": "arn:aws:iam::123456789012:server-certificate/my-server-certificate",
"LoadBalancerPort": 443,
"Protocol": "HTTPS",
"InstanceProtocol": "HTTPS"
},
"PolicyNames": [
"my-duration-cookie-policy",
"ELBSecurityPolicy-2016-08"
]
},
...
],
...
"Policies": {
"LBCookieStickinessPolicies": [
{
"PolicyName": "my-duration-cookie-policy",
"CookieExpirationPeriod": 60
}
],
"AppCookieStickinessPolicies": [],
"OtherPolicies": [
"ELBSecurityPolicy-2016-08"
]
},
...
}
]
}
I have a kubernetes (0.15) cluster running on CoreOS instances on Amazon EC2
When I create a service that I want to be publicly accessible, I currently add some private IP addresses of the EC2 instances to the service description like so:
{
"kind": "Service",
"apiVersion": "v1beta3",
"metadata": {
"name": "api"
},
"spec": {
"ports": [
{
"name": "default",
"port": 80,
"targetPort": 80
}
],
"publicIPs": ["172.1.1.15", "172.1.1.16"],
"selector": {
"app": "api"
}
}
}
Then I can add these IPs to an ELB load balancer and route traffic to those machines.
But for this to work I need to have a maintain the list of all the machines in my cluster in all the services that I am running, which feels wrong.
What's the currently recommended way to solve this?
If I know the PortalIP of a service is there a way to make it routable in the AWS VPC infrastructure?
Is it possible to assign external static (Elastic) IPs to Services and have those routed?
(I know of createExternalLoadBalancer, but that does not seem to support AWS yet)
If someone will reach this question then I want to let you know that external load balancer support is available in latest kubernetes version.
Link to the documentation
You seem to have a pretty good understanding of the space - unfortunately I don't have any great workarounds for you.
CreateExternalLoadBalancer is indeed not ready yet - it's taking a bit of an overhaul of the services infrastructure to get it working for AWS because of how differently AWS's load balancer is from GCE's and Openstack's load balancers.
Unfortunately, there's no easy way to have the PortalIP or an external static IP routable directly to the pods backing the service, because doing so would require the routing infrastructure to update whenever any of the pods gets moved or recreated. You'd have to have the PortalIP or external IP route to the nodes inside the cluster, which is what you're already effectively doing with the PublicIPs field and ELB.
What you're doing with the load balancer right now is probably the best option - it's basically what CreateExternalLoadBalancer will do once it's available. You could instead put the external IPs of the instances into the PublicIPs field and then reach the service through one of them, but that's pretty tightly coupling external connectivity to the lifetime of the node IP you use.
I'm a bit confused about the use of the session stickiness on Amazon Web Services. When I deploy my java web application using Amazon Elastic Beanstalk, I can choose to enable the session stickiness and then specify a cookie expiration period.
My application uses cookies for the session (JSESSIONID) as well as for other small things. Most of the website is accessible only after logging in (I use Spring security to manage it). The website will run on up to 25 small EC2 instances.
Should I enable the session stickiness? If I don't enable it, does it mean that I could be suddendly logged out because the load balancer took me to another server (not the server that authenticated me)? If I enable the session stickiness, do I get logged out when the server that authenticated me gets shut down? Basically, why and when should I use session stickiness?
Thank you very much.
If I don't enable it, does it mean that I could be suddendly logged out because the load balancer took me to another server (not the server that authenticated me)?
Yes
If I enable the session stickiness, do I get logged out when the server that authenticated me gets shut down?
Yes
When using Elastic Beanstalk with a typical Java webapp, I think you will definitely want to enable session stickiness. Otherwise each HTTP request from a user's browser could be routed to a different server.
To get around the issue of the user's session being destroyed when the server they are "stuck" to gets shut down you would need to look into Tomcat session replication. This isn't something that Elastic Beanstalk comes with out of the box unfortunately, so in order to setup session replication you would have to create a custom Elastic Beanstalk AMI for your application to use. Also, you would have to use an implementation of Tomcat session replication that does not rely on multicast, since multicast isn't available on AWS, or any other cloud environment that I know of. An example of an implementation that doesn't rely on multicast would be one that uses a database (such as Amazon RDS) or memcached server (such as Amazon Elastic Cache) to make the sessions available across multiple Tomcat instances.
Also note that the Elastic Beanstalk UI only allows you to enable load balancer-generated HTTP cookies. However after Elastic Beanstalk has created the load balancer, you can go into the EC2 console and modify the load balancer's settings to switch it to application-generated HTTP cookies, and then tell it to use the "JSESSIONID" cookie.
You can also use DynamoDB for tomcat session sharing: http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-tomcat-session-manager.html