Attend code.talks in Hamburg next Month

By Niklas Heidloff, posted on Aug 27, 2015

On September 29th and 30th the developer conference code.talks will take place in the Cinemaxx Hamburg. The organizers expect again 1500 participants who can learn about the latest trends in Java, JavaScript, PHP, Mobile and other popular technologies. Check out the conference program.

IBM will sponsor the conference and there will be an IBM Bluemix booth. My colleagues and I will present and demonstrate Bluemix at the booth and would like to discuss with you cloud programming. The booth will be located between the entries of Saal 1.

We'll have not only great technology at our booth, but also vouchers for the beverages at the evening party on the first day. And even better we want to do two lotteries where you can win two GoPro 4 Black cameras. The first lottery will be on the first day at 16:50 and the second one on the second day at 12:45.

On Tuesday at 14:00 o'clock I'll give a session Rapid Application Development in the Cloud and On-Premises with Docker.
"With the availability of new platform stacks and new tools, the coding of applications has become a lot easier over the last years. However a key problem of software development often still occurs which is the challenge of rapid deployments in different environments - development, testing and production and both on-premises and cloud. The typical developers' excuse "it works for me" doesn't count anymore. Instead today developers are responsible for the complete development cycle up to the deployment and testing in production environments. Fortunately Docker addresses this challenge and makes it very easy to deploy applications in different environments. This empowers developers and allows them to be really innovative by focussing on writing code to go from concept to production in minutes rather than months. In this session we are going to use IBM Bluemix to get applications deployed to the cloud by leveraging the power and portability of Docker containers. We’ll talk about everything from build pipelines, to private registries, container monitoring and more."

Here are some impressions from last year.

IBM MobileFirst Platform Server available as Trial on Bluemix

By Niklas Heidloff, posted on Aug 26, 2015

IBM Bluemix provides several services to build backend functionality for mobile iOS, Android and hybrid apps. There are mobile services to store data server and client side, to handle authentication, to send notifications, to monitor particular apps, ways for users to provide feedback and more. This functionality can be used in mobile apps without additional server side infrastructure.

The IBM MobileFirst Platform Foundation provides the same functionality plus additional functionality needed by enterprises for a complete mobile solution. For example the MobileFirst Platform Foundation server provides mechanisms to monitor not only single apps but all apps used in the enterprise. The server comes also with adapters to access enterprise backend systems and transform the data before returned to clients. For more details check out the MobileFirst Developers site and the blog from Andrew Trice.

In order to try the MobileFirst Platform Server Bluemix provides now a Docker image so that you can set up your own server within minutes. Read the article IBM MobileFirst Platform Server on in under 5 minutes and the documentation Evaluate IBM MobileFirst Platform Foundation on IBM Containers to learn how you can set up your own server.

There is a sample app for iOS, Android, or hybrid environments. The app displays a catalog of items and after users have authenticated they can add items to their whishlists.

This is a screenshot of the MobileFirst Analytics Console:

And here is the sample app running on iOS and Android:

IBM Bluemix allows developers to host their Docker images and to run their Docker containers in the cloud. In addition to hosting Docker in the cloud, Bluemix also provides more than 100 services that developers can use to build applications. There are database services, cognitive services, analytical services, Internet of Things services, services to build mobile backends and more.

Typically when adding these services to applications, the services are provisioned for developers and credentials are created. With these credentials the REST APIs of the services can be invoked and developers can log onto the dashboards of the services. The credentials and additional configuration of the services is put in an environment variable VCAP_SERVICES in JSON format. Applications can access this information at runtime. For example Java applications can use System.getenv and JSON libraries like org.apache.wink.json4j.

For Cloud Foundry based applications services can easily be added via the Bluemix user experience or command line tools. At this point you cannot bind services directly to Docker based applications. Instead you need a Cloud Foundry bridge app. After this you can use the same code to access services in both Docker and Cloud Foundry applications running on Bluemix.

As a developer I prefer to develop code in local IDEs and test and debug it there. Here is what I typically do to access Bluemix services from local applications without having to write additional code. The sample below is an extension to the simple Liberty application.

With Liberty you can use a server.env file to define environment variables. In this file there is one entry VCAP_SERVICES with the value that you can copy from the Bluemix user experience. In order to remove white space you can use different online tools.

The file can be used by the Liberty server running in Eclipse and also by the Liberty server in the local container. Since this file is only needed when running locally a second image is created which extends the one that you can host on Bluemix. The second image simply extends the core image with Liberty and the web application and adds the environment variable to it.

In order to create the images and run the container locally you need to invoke these commands.
root directory: mvn package
directory 'target': docker build -t simple-liberty-image .
directory 'dockerlocal': docker build -t simple-liberty-image-local .
any directory: docker run --name simple-liberty-container-local -p 80:80 -p 443:443 -d -t simple-liberty-image-local

Alternatively as my colleague Richard Osowski pointed out you can run something similar to this:
export VCAP_SERVICES=' (copy & paste VCAP values here) '  note the single quotes as vcap has double quotes
docker run --env VCAP_SERVICES="${VCAP_SERVICES}" ....

Richard also explained in a blog how to update a server.xml file with values from the VCAP_SERVICES variable before the Liberty server is started.
With DevOps pipelines in IBM Bluemix developers can define how to build and deploy their applications, for example applications packaged via Docker. Pipelines can be created manually via the Bluemix web experience and they can be shared as part of the application source code.

This capability is imported when, for example, you want to allow other people to fork your project and deploy it directly to Bluemix via the Bluemix Deploy Button. The documentation describes how to generate a file that includes the pipeline definition. This file needs to be named "pipeline.yml" and put in the directory ".bluemix".

The screenshot below shows how to generate that file. At this point the mechanism might not be the most intuitive one. You have to append "/yaml" to your URL "".

To find out more read the documentation and the blog Forking pipelines from my colleague Robbie Minshall. He describes how to change the generated pipeline file before you should share it by replacing hardcoded values like organization and space names. He also refers to some Bluemix pipeline samples on GitHub that you can use to get started.

Deploying Docker Containers via Bluemix DevOps Pipelines

By Niklas Heidloff, posted on Aug 20, 2015

In addition to the Docker and IBM Containers CLIs (command line interfaces) you can also use IBM Bluemix DevOps pipelines to build images and run containers on the server.

DevOps pipelines have multiple stages. Usually in the first step you build your application code, for example via Maven for Java applications. This can be triggered manually or automatically when pushing code to the source control system (Git in DevOps or GitHub). In a second stage the Docker image can then be built and pushed in the user's access controlled image registry in Bluemix. In yet another stage the application can then be deployed, or in other words containers can be run. You can also leverage other functionality in pipelines, for example globalization or static code security analysis. Read the article DevOps for containers and the documentation How to: Set up continuous delivery for IBM Containers for more details.

Below is a quick sample for how to deploy an as easy as possible Java (Liberty) application. In the first stage the application is built, in the second stage the image is created and in the third stage the container is run.

Using this functionality is pretty straight forward. There was only one little thing that I had to change in my project. I had my Dockerfile in the root directory. Maven created the war file and put it in a target directory which is the base for the second stage. The Docker image could not be created since the Dockerfile was not in that same working directory in the second stage. So I added some code to pom.xml to copy the Dockerfile into the directory "target". After this I could use all defaults in the DevOps UI when creating the stages. I only had to define the names for the image and the container.

As result of the Maven build the Dockerfile (and server.xml) was copied in the target directory with the war.

The Dockerfile is very simple and refers to server.xml and the war in the same directory.

In the server.xml I defined to use the ports 80 and 443.

More Blog Entries ...

Hi, my name is Niklas Heidloff. I work for IBM as an IBM Bluemix Developer Advocate. The blog contains information about IBM Bluemix and articles about my previous work in IBM Collaboration Solutions, esp. IBM Connections and XPages.



The postings on this site are my own and don't necessarily represent my employer IBM's positions, strategies or opinions.