I was hoping to configure Quartz to use Terracotta and the cluster would be built up ad-hoc when my servlet containers started up. All documentation I've seen seems to require the Terracotta cluster to be started up before hand as a separate service.
Is there a way to build the Terracotta cluster into my web application so I don't need to manage multiple services?
Terracotta clustering by default requires at least one separate server to be running. All testing of Terracotta assumes that the server is running alone in the JVM.
So no, there is no support for what you want to do out of the box.
Related
I am newbie in SCDF. I have few micro services running behind Spring Cloud platform. Each services got multiple nodes. Can we use those existing services into SCDF platform as either SOURCE, PROCESSOR or SINK? If so, how would I get them into dashboard as they are already deployed as services!
SCDF doesn't probe on a given K8s cluster/namespace to automatically build the streaming data pipelines.
Today, it is imperative that the streaming/task "definitions" are created and deployed in SCDF first, and only then it is possible to monitor, scale, and manage the applications.
In case it wasn't apparent already, SCDF can only orchestrate the deployment and the management for event-streaming and batch/task Spring Boot applications. Not all kinds of application workloads are possible.
I'm using docker on a bare metal server. I'm pretty happy with docker-compose to configure and setup applications.
Still some features are missing, like configuration management and monitoring maybe there are other solutions to solve this issues but I'm a bit overwhelmed by the feature set of Kubernetes and can't judge if it would help me here.
I'm also open for recommendations to solve the requirements separately:
Configuration / Secret management
Monitoring of my docker hostes applications (e.g. having some kind of dashboard)
Remot container control (SSH is okay with only one Server)
Being ready to scale my environment (based on multiple different Dockerized applications) to more than one server in future - already thinking about networking/service discovery issues with a pure docker-compose setup
I'm sure Kubernetes covers some of these features, but I have the feeling that it's too much focused on Cloud platforms where Machines are created on the fly (since I only have at most few bare metal Servers)
I hope the questions scope is not too broad, else please use the comment section and help me to narrow down the question.
Thanks.
I think the Kubernetes is absolutely much your requests and it is what you need.
Let's start one by one.
I have the feeling that it's too much focused on Cloud platforms where Machines are created on the fly (since I only have at most few bare metal Servers)
No, it is not focused on Clouds. Kubernates can be installed almost on any bare-metal platform (include ARM) and have many tools and instructions which can help you to do it. Also, it is easy to deploy it on your local PC using Minikube, which will prepare local cluster for you within VMs or right in your OS (only for Linux).
Configuration / Secret management
Kubernates has a powerful configuration and management based on special objects which can be attached to your containers. You can read more about configuration management in that article.
Moreover, some tools like Helm can provide you more automation and range of preconfigured applications, which you can install using a single command. And you can prepare your own charts for it.
Monitoring of my docker hostes applications (e.g. having some kind of dashboard)
Kubernetes has its own dashboard where you can get many kinds of information: current applications status, configuration, statistics and many more. Also, Kubernetes has great integration with Heapster which can be used with Grafana for powerful visualization of almost anything.
Remot container control (SSH is okay with only one Server)
Kubernetes controlling tool kubectl can get logs and connect to containers in the cluster without any problems. As an example, to connect a container "myapp" you just need to call kubectl exec -it myapp sh, and you will get sh session in the container. Also, you can connect to any application inside your cluster using kubectl proxy command, which will forward a port you need to your PC.
Being ready to scale my environment (based on multiple different Dockerized applications) to more than one server in future - already thinking about networking/service discovery issues with a pure docker-compose setup
Kubernetes can be scaled up to thousands of nodes. Or can have only one. It is your choice. Independent of a cluster size, you will get production-grade networking, service discovery and load balancing.
So, do not afraid, just try to use it locally with Minikube. It will make many of operation tasks more simple, not more complex.
Try to deploy multiple Usergrid containers on different machines, and make them point to a Cassandra cluster. But I cannot find documents about running multiple Usergrid nodes, and I only found instructions about Cassandra cluster.
Is this the right way to scale up my Usergrid services ? Or, what is the best practice to run multiple Usergrid nodes ?
My understanding is this is the correct way to go about it. You just need to to deploy the ROOT.war file to a new Tomcat instance.
Docs for configuring the usergrid-deployment.properties file so that UG knows where Cass and ES instances are, then deploying to Tomcat are steps 4 and 5 here: https://usergrid.apache.org/docs/installation/deployment-guide.html#deploying-the-usergrid-stack
You can also use the AWS cloudformation scripts in the repo to have AWS handle this for you (https://github.com/apache/usergrid/tree/master/deployment/aws)
There are no documented architecture about scalable usergrid deployment. You need to configure your own deployment based on your requirements. Some samples can be found on the internet, this presentation helped me to configure our usergrid installation: http://events.linuxfoundation.org/sites/events/files/slides/Intro-To-Usergrid%20-%20ApacheCon%20EU%202014.pdf (pages 47-48).
And here is my deployment strategy: All the components (tomcat, C*, es) are java applications, so putting them on to the same machine will be expensive on RAM. So, separate the layers, and scale them independently. For example, if your application chokes on incoming user connections, just scale up tomcat cluster (behind a LB probably). Spend time on configuring Cassandra, and don't stick to the default values - your data will be there and you don't want to lose it.
I am interested in installing OpenStack to a couple of physical we have lying around, and then, somehow, deploying CloudFoundry on top of of it, as the PaaS.
I am also interested in playing around with Docker and CoreOS, and see that an integration between OpenStack and CoreOS already exists.
My question: if I have OpenStack/Nova spinning up VMs running CoreOS, and hence be Docker/container-based, will this be compatible with CloudFoundry, or is CloudFoundry somehow incompatible with Docker containers?
Cloud Foundry is installed using a specialised tool called Bosh. It has support for Openstack and I think would require deployment using Ubuntu VMs (open to correction on this point). Cloud Foundry has not integrated Docker yet, that is coming in the next version, google "Cloud Foundry" and "Diego".
maybe I'm not fully understanding here, but I was under the impression
that containers can't just stand on their own. They would require
living inside a VM. So my thinking/hope was that I could use
CloudFoundry to spin up VM instances, and inside those instances,
deploy containers. Thoughts?
Containers are completely standalone, they are a form of lightweight virtualization. Cloud Foundry is a platform for deploying your application. It runs on virtual machines (or physical servers) and instances of your application are compiled and run on the CF hosts within containers. Currently the container tech used by CF is something called Warden. Diego is a new CF component coming in 2015 that will offer Docker support.
then what is the difference between CF Diego and Kubernetes, which
also seems to be about deploying/distributing your container across
pools of nodes? Do they serve different, similar or identical
purposes? In other words, would there be a use case for having both CF
Diego and Kubernetes managing your app deployments, if so, what?
Kubernetes is a Google sponsored project for orchestrating containers across multiple hosts. Cloud Foundry goes further because it also contains features for building and versioning applications that are deployed. It's worth noting that Redhat have a competing PAAS solution called Openshift. The next version (already available in github) has integrated Kubernetes and added in all the missing application build support, making it comparable to what Cloud Foundry offers. Both CF Diego and Openshift V3 are due for delivery sometime in 2015.
Update
I see from your other questions, you're familiar with Camel. You'd be interested in the fabric8 framework which has recently integrated Openshift V3. (Fabric is the upstream project for the JBoss Fuse product)
I sucessfully managed to complete with my Grail's new website and now i want to run it on my machine to acess it everywhere. I would like to know what is the best approach to do that, i'm a bit noob in what concerns servers and connections. Any help would be aprecciated.
Jm
You need a Java servlet container. The quickest and easiest approach is probably to use Jetty on a Linux system -- most will allow you to install it directly. This allows you run a deployed system from a "war" file. Basically, you would do something like:
grails war
To build the war file, and then copy that (it'll be created in the target directory, with a name based on your application name and version) to the webapps directory for Jetty. On my (Ubuntu) system, that's /var/lib/jetty/webapps/. If you name it root.war, it will serve URLs from the root of the server configuration (typically on port 8080), so http://myhost.mydomain:8080/ will be passed to your Grails application. You'll need to restart Jetty to pick up the new root.war file, e.g., sudo /etc/init.d/jetty restart
Jetty is not the most flexible or powerful servlet container, but it is probably the quickest way to get something up and running, and you can explore more powerful alternatives (Tomcat being an obvious one) as you have time.
Unless you need persistent storage in your app (e.g. end users uploading pictures, etc), you can use Cloud Foundry. It's free for now and makes deployment very easy.
http://blog.springsource.com/2011/04/12/one-step-deployment-with-grails-and-cloud-foundry/
I've been using is via STS and it works really well. There's just one really annoying thing and that's the fact that STS ends up doing a build war with every change.
There's a cloud foundry plugin that gives you command line deployment.
http://www.grails.org/plugin/cloud-foundry
Or there's a Cloud Foundry UI plugin that "provides a simple monitoring UI for your applications deployed to Cloud Foundry. It uses the same API as the Cloud Foundry plugin but is more convenient since runs in a web browser."
http://www.grails.org/plugin/cloud-foundry-ui