Using Tomcat7 on OpenShift Online (free plan), I created a simple Java web application using Apache Wicket as front-end framework. I was wondering how OpenShift deals by default with sessions when an additional gear is started to support a traffic peak.
Are requests within the same session always handled by the same gear, or is it possible that two subsequent requests are handled by different gears?
If requests are handled by different gears, will the session be available on both?
The default behavior that OpenShift uses for HA-Proxy (the load balancer) is session affinity - so each connection should stay on the gear it started on. If it doesn't do that behavior then there is a bug. Please let us know if you see that.
If you want sessions to survive if there is a failure on one of your application servers then you would need to use a server technology that clusters - like JBoss EAP. I am not sure if tomcat 7 on OpenShift is configured for clustering by default.
Related
Classic approach on GCP is rent a linux host with static monthly payment. It doesn't matter if your application is not running or users aren't consuming it, you will always pay the static monthly payment. I think this is acceptable for production environments but for development and testing not.
This does not happen on Heroku :
If an app has a free web dyno, and that dyno receives no web traffic in a 30-minute period, it will sleep. In addition to the web dyno sleeping, the worker dyno (if present) will also sleep.
Free web dynos do not consume free dyno hours while sleeping.
Question
How stop or delete app on google (gae, cloud run, cloud build, containers) if does not receive web traffic?
If it is possible using just google tools it would be great:
https://cloud.google.com/products
Idea
Developing a basic router with nodejs which works as minimal balancer. If web traffic is not detected for some apps, an instruction to google cloud platform api could stop the app or container. This would also apply to other clouds.
Any help is appreciated.
Update
I cannot find any solution yet. I will try to add that feature here https://github.com/jrichardsz/http-operator or a basic shell script to detect incoming request to a specific port like How to print incoming http request on specific port
GCP is offering several serverless products (like you mentioned) and they offer a pricing where you are only charged for the resources you use (when requests are processed).
In Cloud Run you are only billed when an instance is handling a
request using the autoscaling to know more. See their pricing as well for a better overview.
For Google App Engine the app.yaml configuration file contains several settings you can use to adjust the trade-off between performance and resource load for a specific version of your app. You
also check this link how to manage the auto scaling settings.
You can also check this Google Cloud blog for other strategies in auto scaling your applications.
To answer the Comment below:
This video can help you better understand their differences to be able to see the appropriate service for your use case.
To clarify, there's 2 variations of cloud run, the first is managed by google and the other runs on gke. As long as your classic application (api app) is stateless, you should be able to deploy it as a container and take advantage of being charged based on only the resources you use. Snippets would fall under Cloud function where it only runs functions based on triggers.
You can choose to deploy your Cloud Run app on fully managed infrastructure ("serverless", pay per use, auto-scaling up rapidly and down to 0 depending on traffic) or on a Google Kubernetes Engine cluster.
It is also possible to run Docker containers in Serverless using App Engine (Flexible). App Engine is always fully managed, with auto-scaling. App Engine Flex auto-scales gradually and down to 1. App Engine Second Generation auto-scales up rapidly and down to 0.
In your current use case I would recommend to use Cloud Run, check its limitations first before getting started. See the official documentation here and on Cloud Run How-To Guides
I've a spring-boot application which i want to deploy on OVH public cloud.
I need t achieve the goal of deploying multiple instances of the same application, and each instance has to have its own resources (such as MySQL database).
Each instance has to be accessed with a special url. For example:
The first instance is accessable from http://domainname/instance1/index.html
The second instance is accessable from http://domainname/instance2/index.html
I'm really new to everything which concerns cloud computing and deployments.
From what i read on the internet, my doubt is to
Use Docker where each instance has to be running inside its own container (to have the resources separated for each instance)
Use Kubernetes to achieve the goal of having each instance accessable from a specific url.
Am i wrong ? any online courses / resources / videos which can help would be awsome.
Thanks in advance.
Basically, Docker is a platform to develop, deploy, and run applications inside containers, therefore containers represent run-time environment for images. Kubernetes plays the role as an orchestrator and provides sufficient way for building communication channels between containers in the cluster and uses Docker by default as a container runtime.
There are some essential concepts in Kubernetes that describe a cluster core components and application workload, thus define a desired state of the cluster.
Kubernetes objects represent abstraction level of cluster management operations and containerized applications run-time environment within associated resources in Kubernetes API.
I would focus on the Kubernetes resources that are most crucial in application deployment lifecycle.
Deployment is the main mechanism which defines how are Pods should to be implemented within a cluster and provides specific configuration for further application run-time workflow.
Service describes a way how the particular Pod will communicate with other resources within a cluster, providing endpoint IP address and port where your application will respond.
Ingress exposes Kubernetes service outside the cluster with some exclusive benefits like load balancing, SSL/TLS ceritficate termination, etc.
You can get more relevant information about Kubernetes implementation in OVH within particular guide chapter.
Ideally, if it's a single application it should connect to one backend database, not 3 different databases.
If your use case is very specific and you really want to connect 3 instances of an application to 3 different databases then consider each deployed application as an independent application with 3 different deployments.
Talking about Docker and kubernenets, I don't feel you need these initially rather deploy your application directly to the cloud instances. To achieve the high availability of the application, deploy them as a part of autosacing group and map an ELB to each autoscaling group. Finally, map the ELB CNAME in your DNS record and start using your application.
Docker and K8s come with there own learning curve and adds overhead if you are new to this area. Though they have a lot of pros and are extremely beneficial if you have a lot of microservices to manage and have an agile environment.
My preference starts with VM first and then slowly move to the container world. :)
I am developing an application that needs to be clustered in Liberty Profile on BlueMix. I need to have a shared List of objects accessible to all nodes of the cluster. The app will perform update, add and remove operations on them, as one node does not cope with the big load need of the application. How can I do this with Liberty Profile? Is there a best practice or recommended approach before looking for 3rd party solutions for this? Thanks
I would suggest looking at the services in Bluemix, for example Data Cache or Redis. An external (to your app) service would be the cloud best practice for sharing data between multiple instances of the same application or multiple applications that need to communicate.
A traditional Liberty cluster doesn't make sense in Bluemix because the Cloud Foundry platform upon which it is based is already providing ways to achieve high availability and scale.
If we scale up (add an instance to ELB), could we redirect some existing requests to the new instance. So that, The users that we force to a new server will be asked to login again
If we scale down (remove an instance from ELB), then all users from that server will automatically be redirected by ELB to other remaining servers. These user should not be aked to login again.
Is this possible (including the redirect of request)? How?
Any ideas are welcome but I presume this can be solved using a central session store. I just don't know how to implement it .
And what are the options in using a central session store? simpledb? redis? memcached?
Our application is just a simple web application hosted in apache. We have two instances of it added unto the Amazon ELB, and we are using PHP.
Any ELB php specific suggestions? when a scale down/up happens that no user-visible symptomps should be shown?
For the most part, this should be completely transparent to your end users without many changes on your end.
The biggest aspect to look at on your side will be ensuring that sessions are persisted / available through the addition / removal of instances.
You can do this by setting a cookie on the client (default behavior in session_start() and ensuring all of your web servers with PHP have the facility to obtain information about the session id.
Some people will use memcached to do this ... and there is native integration in PHP for sessions to be stored in memcached ...
There are quite a bunch of ways to have a centralized session management. Some of them are listed below:
DB:
http://ocklin.org/session_management_cluster.html
Memcache:
http://www.migrate2cloud.com/blog/how-to-configure-memcached-on-aws-ec2-a-starters-guide (make sure the hosts are able to connect without any problem),
http://www.dotdeb.org/2008/08/25/storing-your-php-sessions-using-memcached/
http://php.net/manual/en/memcached.sessions.php
Msession:
http://in.php.net/manual/en/ref.msession.php
Let’s say I've already deployed a web app on EC2, maybe thru FTP or Remote desktop. So from now on, what would be the best way to update to a new version of my web app?
My main concern would be when running several instances of that web app behind the load balancer: is there a way to update all instances at once so that there are never two instances running with different versions of the web app?
Thanks.
Yeah. Remove each instance from the load balancer (using the API or AWS management console) and update its software, until there is only one instance left. Upgrade that one without removing it, then re-add all the other instances.
There will be no time when the load balancer sends your traffic to two different versions of the software.