We have a big multi module maven project, wich uses cargo to start a tomcat with some wars, a plugin to insert sql data in a postgres database and then using cucumber we run the integration test suit.
I was reading a lot about Docker, and I could play around with it. So here my question,
Can Docker replace my integration test that uses cargo?
What are the benefits?
What about the performance in comparison with the deploy using cargo?
Could a suite that starts containers with postgres and tomcat images improve the build time?
Hope someone can help me here cause I'm pretty exited about docker!
Can Docker replace my integration test that uses cargo?
Yes Continuous Integration Using docker. This jetty container may come in handy.
What about the performance in comparison with the deploy using cargo?
The performance will be about the same maybe a little slower to start up, depending on what you are doing in the Docker container. Docker is more about isolation and repeatability rather than performance. It's way more performant than a virtual machine but not more than Cargo on native host.
Could a suite that starts containers with postgres and tomcat images improve the build time
Maybe, depends on what you are doing currently. You could create a known state in your Docker container and if you were previously manually creating that state then you may find the build to be faster.
The real benefit of Docker is that you can have a well known state in your Postgres database and the tests always run against that known state. Further you do not have to have everyone in your team install Postgres locally. They just need to install Docker and then the rest will be automated. Please often use Docker in conjunction with Vagrant so that even installing Docker can scripted and automated.
Related
I am about to deploy a set of JAVA based microservices.
I am confused as to whether:
Run them as simple jars via "java -jar [JAR_NAME]"
Run them in a JAVA based docker container.
Run them as a war.
Please offer me pros and cons of each implementation as this will save me a lot of headache if I use the suggested best approach :)
Thanks in advance.
Definitely Docker. Using containerization gives you max flexibility.
In your first approach, you jar is dependent on Java. Whenever you create new VM, you need to install fix set of software to support you application.
Benefits in second approach,
First, everything is going to be in single container.
You can install all required software in container and that container can be user in any VM. You have flexibility to use java of your choice for each microservices. Only install docker and everything is going to be worked.
Second, Dev Prod Parity
If you thing very much of microservice architecture and 12-factor apps. Then docker helps to support lots of factors.
Your java and other software are going to be unique in all your environment. That means you are never going to get surprise whether it is working in QA and not in Prod due to some version mismatch of runtime environment.
Third, Flexibility
If you go into microservice architecture, then why only java. You can also go with GO, Python or other languages. At this time, rather installing runtime environment for each platform on each VM it is very useful to have microservice in containers.
Last, Deployment Easiness
You can use docker-compose or docker swarm to run 100s of mivroservice in single command.
I have a Java Spring Boot Application, and I build it with Maven. With
spring-boot-maven-plugin,
I can create fat, executable jar file.
Then I copy it to the remote server and run. But sometimes,
I change only one line or event one word in my code and I had to do whole build/copy step again. I'm sure that I'm doing it wrong, but I couldn't find another way that more efficient (Like capistrano in Rails).
At this point, I'm planning to clone source code to server, push from local, pull from remote, build and run approach. What is the correct (or elegant) way of doing this deployment?
For automatic build and deployment process (continuous integration), you can use Jenkins. Refer this documentation for more details: https://jenkins.io/doc/
I would say it depends where are you trying to do it.
The best and the most agile way to do it for a controlled environment is surely a CI-CD (Continuous Integration and Continuous Deployment) pipelines, which complies-builds-tests-deploys your code against every commit made to the source code BUT it may be too slow to use CI-CD for a development environment where you had like to have a shorter feedback cycle and faster feedback to see how the code is progressing.
However, if you are talking about development environment, I will hit another chord and ask you why to deploy to the external server AT ALL while developing. When you use Spring Boot, which helps you develop a self-contained application, you get the Tomcat Server embedded with it for free. That gives you the choice to run the code anywhere you develop and test to move forward.
A simple maven goal - mvn spring-boot:run can make the code run anywhere you had like.
There is another magical library available in Spring-Boot, known as Devtools, which is meant to support agile developers. The library once in the app classpath, performs hot-swapping of byte-code to auto reload of code into the running application (running locally with embedded Tomcat) as soon there is a saved change. This is one of the coolest gadget that a developer can have.
Use of Spring-Loaded (or JRebel for non spring-boot apps) libraries can also help a developer do hot-swapping of byte code to load changes in running application as soon saved.
I hope it helps.
Is it possible to automate tests on a server using puppet ? I have done some research but cannot find any accurate resources. if its possible, can it be done without the puppet enterprise ?
I am trying to test how much load a software (java server) can handle under different configurations, is it possible to do this using puppet?
If someone can direct me to a good source that'll help a lot.
Thank You.
What kind of testing are you after for this
possible to automate tests on a server using puppet ?
As you know Puppet is about managing your (test) infrastructure, like getting the required this test environment to the desired state (fixtures). My guess is that you need to consider one of the most used CI servers - Jenkins, TeamCity or Bamboo. They all can support your testing process. As example I've used Jenkins and remote physical machine to run
API tests on it, and TeamCity and remote VM for my Selenium grid server.
UPDATE:
For your performance testing you can use some tool like JMeter, framework like Grinder or your own framework implementation with some client like google-http-java-client. And Puppet to tune this java server
under different configurations
per test execution.
I am working on a enterprise product and primarily there are 3 pieces to it swing based client, DB, Server(for now we can ignore DB part). Being enterprise product Client and Server comes with their own installer(it is not like configuring apache or JBOSS and deploy war's on it).
We have CI configured to generate the nightly OS specific builds for Client and server which can be installed.
So we have to test these build regularly on specific OS, which requires a lot of manual process of installing and creating system with X version client on Y OS OR X version server on Y OS. This is becoming very tedious since we are all on windows and doing next-> next -> really sucks(I have created a script which installed our product via shell but then it is still steps which I believe can be automated, but don't how). And also we need an isolation.
Now I am thinking how can we automate this process of creating these test machine. I have just started exploring Vagrant/Docker if they can be helpful to me (and under the their concept, still doesn't understand Puppet/Chef though) and I am confused in which strategy should I adopt
Create VM via vagrant and run my installation script on that box (This will require one VM per Client or per server)
Create VM via vagrant and run my client docker containers on it (this I guess, will require one VM for multiple client or server, since they would be under container)
Note: I have to create VM, since we are on window.either via vagrant or via boot2docker
So my question are
If these 2 strategy are valid and not wrong then out of these 2 which strategy should I adopt out of two ?
Are there any different strategy that I am missing or am I approaching this in right way ?
If strategy #2 is to be adopted then how can I create container/docker images in which my client is installed
how can I create container/docker images in which my client is installed
You must put in a Dockerfile all what you do in order to have your client started and configured.
In order to do so, you can either create a container, do all the stuff, and then docker commit or the better way is to put all the required commands in a Dockerfile, so that when you do a slight modification, you build a new version easily with a basic docker build -t myclient_version_n .
Check the docs
https://docs.docker.com/examples/mongodb/#creating-a-dockerfile-for-mongodb
and how to automate builds
http://docs.docker.com/docker-hub/builds/#automated-builds
how to create a Dockerfile
https://docs.docker.com/examples/nodejs_web_app/#creating-a-dockerfile
and have a look at existing Dockerfiles of containerized application in the docker Hub
https://registry.hub.docker.com/
An alternative to Vagrant would be to use Docker Machine. You could leverage the cloud providers as #m1keil mentioned too. Machine can provision Docker hosts on a number of providers and they are ready to go.
Disclosure: I work at Docker and am the maintainer of Machine :)
Your strategies seem valid to me. The addition of containers (docker) to your process might help you speed up and parallelize the testing process (if it's fully automatic testing) since the initialization time and the general resource consumption of a container are lower. However one cannot give you definitive answer without inspecting your testing process first. And since you haven't provided any details about it, it would be hard to tell you if you should use the first or the second strategy.
You can take advantage of the cloud and use services such as AWS, Azure, GCE, etc to initialize machines and run your tests. You can use Vagrant to do this, or skip Vagrant and create your own simple scripts by using the appropriate APIs of your chosen Cloud provider.
Also you can take a look at services such as Travis.ci, Circle.ci, and others, which might help you created automated testing pipe without the need to spend too much time on the plumbing.
I really like docker's ease of use via the Dockerfile. The Dockerfile let's you very easily update and control the software in the docker image, and then you can provision it in you CI/testing environment. Docker now has native Windows support, so this shouldn't prevent you from being able to use it: https://docs.docker.com/docker-for-windows/ Furthermore, I like that you can setup very lightweight, minimal machines, with only the build and runtime dependencies needed for your project, and store them for free on hub.docker.com. Depending on how long it takes to build & install certain dependencies, this can speed up your testing because you can just download a docker image with everything already installed and built, and then just build and test your actual project.
I use this for https://github.com/sourceryinstitute/opencoarrays, which is GCC's official implementation of Coarray Fortran. I have a little project https://github.com/zbeekman/nightly-docker-rebuild that lets you setup nightly docker image builds on hub.docker.com in under two minutes. I use this to trigger builds of https://github.com/zbeekman/nightly-gcc-trunk-docker-image because I can't rebuild GCC from source on Travis-CI.org without the build timing out. This way, I delegate the GCC nightly build to hub.docker.com and then just docker pull zbeekman/nightly-gcc-trunk-docker-image into a travis-ci instance to test OpenCoarrays against the latest GCC trunk.
Are you supposed to run automated integration tests against a QA server or are you supposed to somehow start an application server from your tests? Does anyone do option #2? How are you supposed to start an application server from tests?
I'm just running into the dilemma of not knowing where to point my selenium driver to. This is a spring java app.
Are you supposed to run automated integration tests against a QA
server or are you supposed to somehow start an application server from
your tests?
As a practical concept, at least the way I see it, the more your test environment(s) looks like your production environment(s), the better. It means that even hardware, location, operational system, etc, have to be considered.
It all comes down to how much "effort" the project is willing to invest on the quality of the product.
You are supposed to run automated integration tests based on your product and project contexts. There isn't a single and final answer to your question, because there are a lot of variables that have to be considered.
Does anyone do option #2?
Yes, I do use a embedded application server but I only used it for database integration but you can apply that for functional automated testing as well.
How are you supposed to start an application server from tests?
One option is to use embedded containers that you can manage with Maven profiles. I recommend you to follow this Arquillian Getting Started guide to understand how it works, and then you can apply the same concept for Selenium and Spring.
I usually go with option 2 -- I use the Maven Jetty Plugin to start an application server running the webapp (usually under a 'test' profile to swap out certain dependencies like the database) and then run Selenium against the locally hosted application. You can bind the Jetty plugin to pre-integration-tests, and stop it in post-integration-tests.
I typically also include the JaCoCo plugin to instrument the Jetty JVM so that I can check coverage from Selenium-style integration tests.