WaveMaker hosts applications for thousands of users built using wavemakeronline.com. Keeping promise of free hosting upto 300 days wasn’t a very easy target. Even the smallest of VMs would not have been economical enough. This is when, a year and half ago, we explored containerization and saw that Docker was trying to provide very usable tools for containerization. We were able to break instance in smaller partitions using container technologies and accommodate many more users on the same infrastructure. Also as containers provide a lighter form of virtualization and can be launched in a few milliseconds, we could start the whole container on a user web request. This led us to further optimize the deployments by passivating the application not being used.
Building this platform provided us a lot of learning, which we want to get to the enterprises. Docker based infrastructure provides containers, which can be shipped to different environments with minimal effort and configuration. Though, enterprise finds it challenging to leverage these technologies as these are still scattered.
WaveMaker Enterprise provides an enterprise solution, which can help enterprises save this complexity and achieve advantages including simplified and automated application delivery, optimized resource utilization along with other enterprise features including monitoring on all levels, role-based access control, release management, data backup, and recovery etc…
For an idea on what WaveMaker Cloud offers you, take a quick look at the WaveMaker Cloud page. Let me list down the top features for the sake of completeness of this post
- Micro-service Architecture for application deployment with easier versioning and upgrades of application and platform.
- IT Certified Software Stacks provisioning and configuration
- Continuous Delivery with reusable Software Stacks with minimum configuration.
- Comprehensive monitoring and management of applications, containers and infrastructure
In a Micro Service Architecture based application deployment scenario, these are typically the steps followed:
1. IT Administrator creates the private cloud environment either using infrastructure from their data center or from IAAS providers.
2. Enterprise Architect defines the various microservices and their software dependencies for deployment.
3. DevOps Engineer then is responsible for hardware provisioning from the private cloud for all the services defined by the Enterprise Architect and deploy services.
In the world of WaveMaker Enterprise Cloud, the above steps translate into the following steps...
1. The IT Administrator easily creates a Docker-based Private Cloud infrastructure using WM Cloud’s DIY-based cloud management console.- He will create shards, to represent dev, staging & production environments,- Add physical instances to it, where containers get provisioned. The shards are available for selection when the applications are getting deployed
2. Enterprise Architect creates an Application Stack which represents the collection of configuration details of all the microservices (Services). The Service itself would have been created by either by the EA or a team of app developers working on that particular microservice. The service configuration can contain one or more software components called Packages, which defines it. For example, a web service can have the packages of Apache Tomcat and Java run time.
3. DevOps will use the service configurations and the package definitions are snapshotted as a Docker Image which is stored in a Private Enterprise Registry. DevOps is also responsible for configuring the provisioning requirements for each of the service. These requirements range from selecting the size of container (viz. XL, L, M, S) to the number of containers per service for scalability.
In this post we will see how to quickly setup deployment of a WordPress application and replicate them consistently with minimal effort and configuration.
Let’s start with some terminologies.
Any application can be deployed to one or more environments referred as Application Environment. These can be configured for different stages of application delivery e.g. staging, production, etc.. or these can also be some other environment as customer dedicated environment etc..
Application Stack represents a reusable deployable application with all its services in a logical group. This can be deployed on more than one application environment expediting application delivery. The minimum configuration is required for deploying an existing Application Stack on different environments. An Application Stack may consist of multiple services.
A Service (Image) represents a micro-service in the deployment of an application. E.g. MySql , Apache2 can be 2 different services in an application stack. Service is based on an Image that consists of multiple packages. The image actually maps to a DockerFile. It requires may require some configuration variables which can be supplied when the Application Stack is configured in a new Application Environment.
A service consists of multiple packages. E.g. a Tomcat service will need Java and Tomcat packages. Other than that a package in WaveMaker Enterprise can also specify the configuration variables needed at runtime. The values of configuration variables can be provided when Application Stack is deployed on a specific environment.
A Package can easily be configured with a few scripts in WaveMaker Enterprise. Existing scripts can be used to create a package.
A service (Image) can be created on the top of one of the base images. Base images are Docker images hosted in a private image repository in an enterprise. A new base image can be downloaded from the Docker repository, or can also be created and uploaded to a private image registry.
In this example, we will take a simple case of deploying a WordPress application on WaveMaker Enterprise. We will simplify it to use only one service consisting of packages Apache2 with PHP, MySQL, and WordPress. You need to have WaveMaker enterprise installed and need to register as a valid user to it.
Provide information including the name of the package, version. Other than this vendor and OS which will run this package can be provided.
You can specify the files needed for the installation, configuration, and start of this package. These files can be the script files that you need to execute, of the other required files for the package. They will be uploaded to a directory with the name /wm/<packagename>, where the package name is the name of the package you specified in the previous step.
Other than this we need to provide the commands to add these packages. The following are the commands
Installation Commands [Executed during installation]
chmod 777 /tmp && apt-get -y install mysql-server-5.6 mysql-client-5.6
Configuration Commands [Executed during configuration, uses the value configured for configuration variables during Application Environment creation, e.g. MYSQL_ROOT_PASSWORD]
#Permit Root User to Login
sed -i -e"s/^bind-addresss*=s*127.0.0.1/bind-address = 0.0.0.0/" /etc/mysql/my.cnf
#change root password, the password value is taken from env property named MYSQL_ROOT_PASSWORD
mysql -uroot -e "GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION";
mysql -uroot -e "UPDATE mysql.user SET Password=PASSWORD('$MYSQL_ROOT_PASSWORD') WHERE User='root'";
mysql -uroot -e "FLUSH PRIVILEGES";
Startup Commands [Executed to start the package component. E.g. MySQL in this case.]
In this step, you specify the ports that need to be exposed for this service to be consumed. Also, the configuration variables required by the package need to be added in the Required field. E.g. MYSQL_ROOT_PASSWORD in the screenshot above.
Exposed configuration variables are those set by this package and can be consumed by other packages in the service. E.g. JAVA_HOME can be configured by the installation of a Java package and can be consumed by the dependent packages.
Apache2 with PHP
# apache installation
apt-get -y install apache2 libapache2-mod-php5
apt-get -y install php5-mysql pwgen php-apc php5-mcrypt
sed -i "s/KeepAliveTimeout 5/KeepAliveTimeout 300/g" /etc/apache2/apache2.conf
Specify port Http/80 and https/443 on the configuration page.
# Install WordPress
wget -O /tmp/wordpress.zip https://wordpress.org/latest.zip
# db creation for wordpress requires env properties such as MYSQL_ROOT_PASSWORD, WORDPRESS_DB_USER, WORDPRESS_DB_PASSWORD
mysql -uroot -p$MYSQL_ROOT_PASSWORD -e "create database wordpress";
mysql -uroot -p$MYSQL_ROOT_PASSWORD -e "CREATE USER wordpress@localhost IDENTIFIED BY 'wordpress123';"
mysql -uroot -p$MYSQL_ROOT_PASSWORD -e "GRANT ALL PRIVILEGES ON wordpress.* TO wordpress@localhost;"
mysql -uroot -p$MYSQL_ROOT_PASSWORD -e "FLUSH PRIVILEGES;"
cp wp-config-sample.php wp-config.php
sed -i "s/database_name_here/wordpress/g" wp-config.php
sed -i "s/username_here/wordpress/g" wp-config.php
sed -i "s/password_here/wordpress123/g" wp-config.php
chown -R www-data.www-data *
Let’s create image with name wordpress choosing base image of Ubuntu 14.04 and provide it a version 1.0.
Now add packages we created to this Image and order the packages in the right order by simple drag and drop. WordPress Package is kept in the end as it will depend on the other 2 packages.
You can see the DockerFile generated for the Image. Also other scripts involved can be looked at.
You can see the logs of Docker Image build and push.
After this we can configure a service from an Image providing the default values for the configuration properties. These properties can be modified later while configuring the environment.
You can create an Application Stack by selecting the services you need to add. We are adding WordPress Service we just created here.
Provide a version, application stack, and shard to which we need to deploy the WordPress application. As we saw earlier shards were configured by the IT Administrator for logical slicing of the enterprise cloud. Please select the default shard here.
Also, we need to provide the number of nodes and the strategy for balancing the load. I am choosing a simple Round Robin strategy. Container type will decide the size of resources available to the WordPress applications.
We can configure the server URI for application deployment.
Values of configuration variables can be modified here for environment-specific values.
Access the application on https://wordpress.demo.nwie.net/wordpress/index.php
We saw in this blog, how simple it is to create a reusable application stack and deploy it in any environment with minimum configuration. This really provides great optimization and continuous deployment of enterprise applications saving long release cycles. Please contact firstname.lastname@example.org for a demonstration and more information.