Stay informed

Jelastic Joker Release 4.0 with Advanced Docker Containers as a Trump Card

Jelastic presented Docker technology updates within improved UI, providing ability to scale containers horizontally, redeploy without downtime and swap custom domains.

Palo Alto, Calif., October 20, 2015Jelastic, Inc., a leader in cloud container orchestration and DevOps workload mobility, today announced their latest release named Joker (Jelastic + Docker), to represent the company’s latest innovations in Docker technology.

“After integration of Docker containers to the Jelastic we’ve got lots of positive feedback and kept on working to make this technology even more advanced within our cloud platform. The Joker release brings flexibility and security for DevOps with сontainers to the next level,” Ruslan Synytsky, Jelastic CEO.

Docker has been integrated to Jelastic platform about a year ago. Since that time a set of enhancements was implemented to improve the performance and user experience. The enlarged number of available possibilities, let developer and system administrators tune their containers. Docker engine was also updated from 1.6.2 to 1.8, that gives Jelastic users the ability to work with Docker Registry 2.x repositories.

« We are proud to be a Jelastic partner, and especially excited about their enhanced support for Docker. Jelastic is built upon the Virtuozzo platform, whose combination of containers, hypervisors, and virtualized object storage is used in over one million production instances, » said John Lawler, Sr. Director of Virtualization Product Marketing at Odin. « Jelastic’s latest release further strengthens a highly scalable platform for easily building secure production solutions for service providers, enterprises, and DevOps. »

Docker related improvements include, but not limited to

  • Horizontal Scaling for Docker Containers

One of the most significant features of this release is that Docker containers in Jelastic can now be scaled horizontally, as well as vertically.

  • UI Redesign for Better User Experience

The user interface for a Docker container orchestration has been redesigned to be even more intuitive.

  • Custom Domains for Docker

Added the ability to bind and swap custom domain names to Docker containers for users to update their project and test these changes with zero downtime deployment.

  • Support of Stateful Containers with Live Migration

Live migration allows to move stateful apps from one hardware region to another without downtime and with no need to restart and re-deploy containers.

  • Software Defined Storage for Containers

Improvements related to infrastructure fault tolerance allow to restore automatically Docker containers at their latest state in case of hardware fail.

  • Native Virtuozzo OS Template for Docker Containers

Better integration with Virtuozzo technology to improve security and isolation of Docker containers.

  • Pre-Installation Access to Docker Container Settings

Now a developer can browse, edit and apply any necessary changes of environment variables with no need to download the whole Docker image in advance.

  • Docker Volumes

Volumes are used to securely store the data out of the container, while different internal operations are performed such as redeploy of a container with another tag version.

  • Docker Container Redeployment

An existing Docker container can be easily updated to a new version with all previously defined settings. Multiple identical Docker containers can be re-deployed sequentially or in parallel.

  • Auto Redirect of Docker Application Port

Applications inside Docker containers can get the incoming requests via shared load balancing with no need in Public IP.

To view the full list of new features and improvements of Jelastic Joker 4.0 look through our Release Notes.

« Thanks to innovations in Jelastic Release 4.0, we are entering a new level of production-ready Docker Hosting. Our customers profit of an unmatched simplicity and scalability when managing their Docker Containers on our Swiss-based Cloud Platform.« , says innofield co-founder Reto Giezendanner.

20/10/2015
Tags :, ,

Self-Signed SSL Certificates at Jelastic Cloud: Develop, Test and Run Your Secured App

While hosting your application, you can face the problem of securing the data operated inside, especially if this data is private and should be transferred between clients and a server. One of the commonly used ways to ensure such protection is encrypting this communication with the help of the SSL (Secure Sockets Layer) protocol.

In order to establish the SSL connection, your web server needs to have the appropriate certificate applied. With Jelastic Cloud, you can use two types of certificates: Jelastic SSL and Custom SSL. The first one is the most rapid method to enable the SSL protection for your environment with the default hostname (this can be done directly through the environment topology wizard). Otherwise, if you’d like to get more functionality and bind the custom domain name for your application, the right choice is to use the Custom SSL certificate (we’ve covered the process of its generation and installation in one of our previous publications).

Herewith, all custom SSL certificates require to be signed, and usually this is done by the Certificate Authority (CA) companies. In this case, your certificate becomes reliable after signing, so others can trust it and any connection to your site or application is performed without issues.

Nevertheless, you can sign your custom certificate yourself and still receive a secure connection, but such a certificate will be untrusted. As a result, while opening your application it will require visitors to pass through the warning message, that highly recommends they leave your web page because of the untrusted secure connection.

warning

Such a denotation can confuse inexperienced users, so we suggest using the self-signed certificates only for non-production purposes. It’s a good solution for development/testing instances or for your own private site with a small audience, aimed to gain the increased security without passing the checks and waiting for approval from the CA.

So, let’s find out how to create a Self-Signed Custom SSL certificate and apply it to the Jelastic environment.

Generate a Self-Signed SSL Certificate

In order to generate a self-signed certificate, you need to buy a Domain name first (e.g. mysite.com) using any domain registrar.

Once that is done, you can proceed to generation of your SSL certificate with the help of any preferred tool. We’ll use OpenSSL as an example.

Perform the steps below in order to create an SSL certificate using your local machine (the instruction varies due to your operating system: Windows or Linux/MacOS/FreeBSD) or Elastic Virtual Private Server at Jelastic Cloud.

For Windows

Download the latest OpenSSL tool version. Extract the received archive and run the tool by double-clicking the openssl.exe file in the bin folder. Subsequently, the files created with OpenSSL will appear in the same bin directory by default.

1. First, you need to generate an SSH private key for your root certificate (this is what signs all issued certificates). Create it as follows:

genrsa -out {filename} {length}

where

{filename} – name of the output key file with .key extension (e.g. rootCA.key)
{length} – private key length in bits (e.g. 2048)

w 1

2. Then you should generate the root CA certificate based on the prepared key. Use the req command with the x509 option flag for outputting a self-signed root certificate instead of a certificate request:

req -config {config_path} -x509 -new -key {keyname} -days {days} -out {filename}

where

{config_path} – path to the openssl.cnf configuration file, located in the directory with extracted OpenSSL files (specified according to the C:\path\to\openssl.cnf format)
{keyname} – your root key name (the one you’ve generated in the previous step, rootCA.key in our case)
{days} – number of days the current certificate will be valid
{filename} – the preferred name of the output certificate file with .crt extension (e.g. rootCA.crt).

Set the required information for your CA certificate by answering the appeared question.

w 2

As a result, you’ll receive a self-signed root certificate for your own CA.

3. Now, you can create a private key and self-signed certificate for your purchased hostname. Let’s start with the key: generate it in the same way you did for the root one.

genrsa -out {filename} {length}

where

{filename} – name of the output key file with .key extension (e.g. host.key)
{length} – private key length in bits (e.g. 2048)

Note: DO NOT protect your key with a passphrase, otherwise you’ll get an error during its addition to the Jelastic dashboard.

w 3

4. Next thing you need is a certificate signing request (CSR). Execute the following command:

req -config {config_path} -new -key {keyname} -out {filename}

where

{config_path} – path to the openssl.cnf configuration file, located in the directory with extracted OpenSSL files (specified according to the C:\path\to\openssl.cnf format)
{keyname} – your server key name (the one you’ve generated in the previous step, host.key in our case)
{filename} – the desired name of the output request file with .csr extension (e.g. host.csr).

You’ll see a set of questions appear again. Answer them in order to complete the certificate information with your data.

IMPORTANT: Note that the Common Name parameter value has to be equal to your purchased domain name, otherwise your certificate won’t be validated.

w 4

5. The final step is generation of your self-signed certificate based on the created request with the help of a root CA certificate. For that, we’ll use the x509 command with the following options:

  • -req – means that certificate request input file format is expected
  • -CAcreateserial – initiates creation of the CA serial number file (if it does not exist)
x509 -req -in {requestname} -CA {CA_certificate} -CAkey {CA_key} -CAcreateserial -out {filename} -days {days}

where

{requestname} – name of the input request file (host.csr in our case)
{CA_certificate} – specifies the CA certificate that will be used for signing (rootCA.crt in our case)
{CA_key} – sets the CA private key to sign a certificate with (rootCA.key in our case)
{filename} – the desired name of the output certificate file with .crt extension (e.g. host.crt)
{days} – number of days the current certificate will be valid

w 5

Great! Now you have the self-signed SSL certificate for your application.

For Linux/MacOS/FreeBSD

In case you don’t have the OpenSSL tool installed yet, get it with the appropriate command (according to your OS package manager) executed within your terminal. E.g. for Ubuntu/Debian Linux distribution use the following one:

sudo apt-get install openssl

When the installation process is completed, proceed to generation of the required files. All newly created with OpenSSL files will appear in the home directory of your local machine user by default.

1. First, you need to generate an SSH private key for your root certificate (this is what signs all issued certificates). Create it as follows:

openssl genrsa -out {filename} {length}

where

{filename} – name of the output key file with .key extension (e.g. rootCA.key)
{length} – private key length in bits (e.g. 2048)

1 gen cakey

2. Then you should generate the root CA certificate based on the prepared key. Use the req command with the x509 option flag for outputting a self-signed root certificate instead of a certificate request:

openssl req -x509 -new -key {keyname} -days {days} -out {filename}

where

{keyname} – your root key name (the one you’ve generated in the previous step, rootCA.key in our case)
{days} – number of days the current certificate will be valid
{filename} – the preferred name of the output certificate file with .crt extension (e.g. rootCA.crt).

Set the required information for your CA certificate by answering the appeared question.

2 gen cacert

As a result, you’ll receive a self-signed root certificate for your own CA.

3. Now you can create a private key and self-signed certificate for your purchased domain. Let’s start with the key: generate it in the same way you did for the root one.

openssl genrsa -out {filename} {length}

where

{filename} – name of the output key file with .key extension (e.g. host.key)
{length} – private key length in bits (e.g. 2048)

Note: DO NOT protect your key with a passphrase, otherwise you’ll get an error during its addition to the Jelastic dashboard.

3 gen hostkey

4. The next thing you need is a certificate signing request (CSR). Execute the following command:

openssl req -new -key {keyname} -out {filename}

where

{keyname} – your server key name (the one you’ve generated in the previous step, host.key in our case)
{filename} – the desired name of the output certificate file with .csr extension (e.g. host.csr)

You’ll see a set of questions appear again. Answer them in order to complete the certificate information with your data.

IMPORTANT: Note that the Common Name parameter value has to be equal to your purchased domain name, otherwise your certificate won’t be validated.

4 gen hostreq

5. The final step is generation of your self-signed certificate, based on the created request with the help of the root CA certificate. For that, we’ll use the x509 option with the following flags:

  • -req – means that certificate request input format is expected
  • -CAcreateserial – initiates creation of the CA serial number file (if it does not exist)
openssl x509 -req -in {requestname} -CA {CA_certificate} -CAkey {CA_key} -CAcreateserial -out {filename} -days {days}

where

{requestname} – name of the input request file (host.csr in our case)
{CA_certificate} – specifies the CA certificate that will be used for signing (rootCA.crt in our case)
{CA_key} – sets the CA private key to sign a certificate with (rootCA.key in our case)
{filename} – desired name of the output certificate file with .crt extension (e.g. host.crt)
{days} – number of days the current certificate will be valid

5 gen hostcert

Great! Now you have the self-signed SSL certificate for your application.

Elastic VPS

You also have the possibility to create your self-signed certificate using the Elastic VPS server. For that you need to:

  • create an environment with Elastic VPS inside
  • connect to it in the preferred way (using Public IP or via SSH Gateway)
  • access the OpenSSL shell with the corresponding opensslcommand
  • create a self-signed certificate following the Linux/MacOS/FreeBSD section of this guide (the only difference is all the commands should be executed without the openssl word at their beginning, as you are already inside the OpenSSL shell).

Once the generation process is finished, you need to download the created certificate files (in order to apply them to the necessary environment afterwards). To do this, exit the OpenSSL shell using the exit command and run a simple HTTP server:

python -m SimpleHTTPServer

vps http server

It will be used for downloading the required files. Therefore, access the started server by means of typing the next URL into your browser’s address bar:

http://{vps_ip}:{port}

where

{vps_ip} – external IP of your VPS node; can be found by clicking the Additionally button for your CentOS server (the required address will be the second one) or in the email with its administration data you’ve previously received
{port} – port number the HTTP server has been run at (can be seen just after the line with executed command, 8000 in our case)

Depending on your hosting provider, you can be faced with an unavailability to establish the connection to this server due to the enabled firewall protection. In this case, return to your VPS console and enter the following line to it:

/etc/init.d/iptables stop

vps firewall stop

Then, run your HTTP server again and refresh the browser page with the abovementioned URL specified.

You’ll see the list of files, available inside the directory you’ve run the HTTP server in.

http server

Download the required certificate files (circled above) to your local machine.

Great! Now you have the self-signed SSL certificate for your application.

Adjust Environment Topology and Set A Record

1. In order to be secured with any custom SSL certificate (regardless if it is signed by a real CA or the self-signed one), your environment should be configured in a proper way, i.e.:

  • contain at least one application server
  • have a single entry point with the Public IP address enabled

The detailed instruction can be seen in the Adjust Environment Topology section of the Custom SSL document.

2. Once all of the required configurations are performed, you need to bind your application’s Public IP to the previously purchased domain name by means of setting an A Record. This can be done with the help of the DNS Manager of the chosen domain registrar.

In order to get the Public IP address of your application, select the additional button additionaly for a node in your environment it was attached to (i.e. for the NGINX-balancer server in the case of Python/Node.js usage, or for the application server in all other cases).

You’ll see the list of IPs, wherein the second one is the required Public IP address.

ext ip

For additional information, see the corresponding instruction (starting from the 5th step of the Domain Name and A Record Settings section).

Upload Self-Signed SSL Certificate to the Environment

The last thing you need to do is to add the created certificate files to your environment.

1. Click the Settings button for the appropriate environment.

settings

2. In the opened tab, choose the Custom SSL option within the left-hand list.

Upload Server key, Intermediate certificate (CA) and Domain certificate into the appropriate fields (in our case, the required files are host.key, rootCA.crt and host.crt respectively).

If you’ve received an error at this stage, ensure your private SSH host key is not protected with a passphrase. Otherwise, remove the protection with the following command and try to upload the files again:

openssl rsa -in {keyname} -out {new-keyname}

custom ssl

Click Save.

3. When the servers in your environment are automatically restarted, you can ensure everything works properly. For that, enter the binded custom domain name (or the attached external IP address) into your browser’s address bar with the https:// connection protocol specified instead of the default http:// one.

You’ll see the page with warning message opened, informing you that the used SSL certificate is not trusted. Since it’s your site, click the Proceed anyway button (or the similar one, depending on your browser).

warning-chrome

For some browsers (e.g. Mozilla FireFox), even if you’ve decided to proceed, it’s required to add this page to your browser’s exceptions list before you are able to continue.

warning 2

After that, you’ll be redirected to your site via the encrypted protocol.

https

That’s all! For now, you can be confident that interaction with your application is performed safely.

To confirm that it really is that simple, register now to start a 2-week free trial period, deploy your application, and install a self-signed certificate in just a few minutes!

22/12/2014
Tags :, , ,
blog_docker

Luxembourg Web Service Powered by Jelastic Announces Docker Integration to Provide the Most Advanced Orchestrated Application Delivery

Jelastic, Inc., the first company that combined unlimited PaaS (Platform-as-a-Service) and IaaS (Infrastructure-as-a-Service) into one solution, has announced integration with Docker using Parallels Cloud Server. The collaboration will allow service providers to enable continuous application delivery, fully elastic scalability and integrated orchestration and management for hosting applications in the cloud. This is the first industry solution that combines Docker’s application delivery approach and Parallels containers, fully managed via Jelastic PaaS.

Docker, Jelastic and Parallels Cloud Server are complementary to each other. Docker addresses application assembly, delivery and portability; Jelastic provides orchestration and management for hosting applications in the cloud; and Parallels Cloud Server offers container and storage infrastructure performance and availability.

“Docker is the best application format delivery ever! The Docker team has shifted the containers conversation in the marketplace to help bring a renewed focus on containers virtualization technology and how it can be utilized with a new application delivery format. By leveraging containers technology from the beginning, we’re confident our long-term strategy in the PaaS layer is solid,” said Ruslan Synytsky, CEO of Jelastic.

“We believe the evolution of Docker is not finished yet and requires more attention on the virtualization layer to finally deliver the promised high density, together with an advanced level of security and live migration of containers on top of bare metal hardware. It’s obvious that hosting of Docker templates inside a VM is not efficient enough and can be improved to deliver the original promise of containers virtualization. Moreover, this point becomes dramatically important if you think about economy, TCO, performance, licensing and management complexity of private cloud and cloud-in-a-box solutions designed for DevOps. So we are very pleased to announce the first industry solution that contains an extremely useful application delivery approach from Docker and the most mature containers, virtualization technology from Parallels,” concluded Synytsky.

Docker standard in Jelastic allows the companies to reach a wider market of public and private cloud customers who require more automation, security, optimization of resources consumption and flexibility, while setting and managing their applications, clusters and services.

“Containers have been a well known technology to hosting service providers since 2001. They are used by thousands of hosting service providers around the world for hosting millions of end users’ applications in a very cost-effective way. Jelastic is pioneering a cloud platform which uses Parallels Virtuozzo Containers to deliver services. The combination of the Docker deployment and highly secure containers virtualization from Parallels allows Jelastic to provide the most cost effective platform for hosting both public and private clouds.,” said James Bottomley, chief technology officer, Virtualization, Parallels. “Our work with Jelastic means that Docker users can now run their containers securely and at high density within Parallels Cloud Server.”

Increasing Functionality for Service Providers
With the integration of Docker standard across the Jelastic platform, users will now have more flexibility and options while installing any stack, application or system.
Customers will also get the added benefits of Parallels Cloud Server and Jelastic PaaS. Features include the following:

  • Live migration of Dockers: Cloud service providers will be able to migrate Dockers from one physical server to the other with zero downtime, increasing operational efficiency.
  • Granular division of physical servers into containers with Docker but not into VMs: As a result, a user is not restricted with limited resources of the virtual machine, but can scale the application throughout the whole server.
  • High density and maximum utilization of server resources: This results in the best return-on-investment for the customer.
  • Full isolation and security of containers: Each Docker gets complete privacy and becomes unavailable for other users due to the full isolation of RAM, CPU, IO, filesystem and network for each container.
  • Smart distribution of Docker from one environment evenly on different physical servers: This eliminates any risk of application downtime if one of the physical servers has any issues with performance and provides high availability of users’ applications.
  • Optimal use of resources with the help of hibernation: Non-active Dockers can be hibernated automatically and do not consume resources (only disc space), the released resources are returned back to the cluster.
  • Automation and resource management: Automatic vertical scaling ensures that Docker will get the required resources in time and will not face any performance degradation. For public cloud users this approach significantly saves money as they pay only for what they use, instead of trying to use what they pay for.
  • Full orchestration: With Jelastic, you get all necessary services and tools for managing your Dockers (creating clustered solutions, setting load balancing, etc.) out-of-the-box right from the admin panels (for developers and cluster admins).

Jelastic, with the support of Docker standard, will provide developers with a joint platform that lets them easily host and manage all types of applications or services, within a wide choice of datacenters around the world. Docker’s lightweight, simplicity, portability and appeal to developers will become a positive addition for Jelastic’s flexibility and technology superiority on the cloud market.

“Everybody talks about Docker, the hyped application format delivery,” said Timo Mankartz, CEO of dogado GmbH. “Docker is the first technology that makes it possible to standardize application containers. For Jelastic, Docker offers enormous potential when it comes to our 0-Vendor-Lock-In concept in Jelastic. With Docker, we allow it to package and migrate applications along with their dependencies between all Docker compatible providers.”

Sources

24/11/2014
Tags :, , , , , ,
Get a 14-day Trial ! Content