This workshop walks you through hosting your web application in Bluemix. It is a prerequisite for all the other Etherpad series of workshops. To get your web application up and running, you’ll need to complete the steps in Task 1 through Task 6. This workshop has the following sections: Contents:

Introduction

In this introduction you’ll learn important concepts and architectural considerations for using Bluemix to host a web application on the cloud. You will also learn about Etherpad, a collaborative web application used as a reference in this Workshop and a series of follow-on Workshops to help you explore more services.

Why deploy your application on Bluemix

There are many different types of web applications running on the Internet today. There are also just as many ways to manage and maintain the infrastructure powering those applications. IBM Bluemix delivers quick and easy cloud capabilities to deploy and maintain your web application, with minimal hassle and overhead. Applying industry-adopted standard architecture capabilities into our application deployments allow us to confidently advance and grow our infrastructure. Hosting applications on Bluemix provides users with a lot of advantages. Bluemix is an end to end offering that provides developers with a complete set of DevOps tools and integrated services to simplify development, test, build and deployment of applications. Moreover, Bluemix-hosted applications have access to the capabilities of the underlying cloud infrastructure. Such infrastructure provides the best support for non-functional requirements that are needed to support enterprise applications such as scalability, performance, availability, and security. Furthermore, Bluemix provides a rich set of services to extend your application through incorporation of sophisticated analytics, social and mobile capabilities. Finally, the Bluemix platform frees developers and organizations from worrying about infrastructure-related plumbing details and focus on what matters to their organizations – business scenarios that drive better values for their customers. The subsequent sections discuss the main considerations for deploying your web application with IBM Bluemix and provide an architecture overview. We suggest that you go through these sections first before starting on the ‘Etherpad Series’ Workshops.

Introduction to the Etherpad web application

Etherpad logo
Etherpad is a highly customizable Open Source online editor providing collaborative editing in really real-time.
In the ‘Etherpad Series’ Workshops, you will deploy a collaborative-editing web application, taking advantage of certain architecture elements of a web application hosting pattern, and extend it using some of the services available on Bluemix. This application, Etherpad Lite, is an open-source project built for real-time collaboration, with extensibility options which will easily allow for future integration of additional capabilities as needed. In this scenario, we play a developer tasked with managing an Ethernet Lite deployment. The current deployment is on-premise, which means we also need to manage the middleware and database infrastructure supporting the application as well. The machines dedicated to powering the environment are reaching capacity, and we can’t request more hardware, making it difficult to grow the infrastructure. We’d really prefer to move the deployment elsewhere, to a more scalable environment where we can easily add more instances as teams increase in number and usage, and to a managed environment so we can focus on the development work as opposed to maintaining servers. A cloud environment would be a great fit. However, we don’t want to rewrite the application; we want to run the existing code. Fortunately, IBM Bluemix has just released their container service, so we can easily deploy our Etherpad Lite web application into containers running off-premise that will give us the ability to easily develop, test, and roll out new features for our users. Some of these capabilities that we want to target immediately are hosted database services to externalize the data of our Etherpads, integrating with IBM’s Watson Question and Answer service; all of this being possible by building our application on Bluemix! With our choice of architectural elements we hope to realize speed, flexibility and return on investment. Bluemix enables us to deploy our application instantly to multiple environments such as test, development, pre-production and production, multiple versions or releases with agile/pipeline/DevOps-oriented integration. We also have the ability to integrate with on-premise enterprise resources through the built-in hybrid integration capabilities of Bluemix, targeting anything with an API or hostname and port behind our firewall! To say it simply, building our application on Bluemix enables us to grow quickly and securely, while also realizing cost and time savings, and at the same time build on industry-proven architectures.

Cloud architecture overview for web app hosting

Through this workshop series, we will incrementally grow our capabilities to adapt a standard web application into an architecture more in-line with an industry proven architecture for web application hosting. This web application hosting reference architecture (shown below) and documented at the Cloud Standards Customer Council Resource Hub, covers in detail everything from the user requesting the initial URL all the way through the backend data calls.
Web application hosting reference architecture
Web application hosting reference architecture
The following explains the components of the web application hosting reference architecture:
  • Inbound user requests are initially handled by Domain Name Services, which route your traffic to the proper infrastructure endpoints.
  • Content Delivery Networks provide the least latency and the highest speed to create an exceptional end user experience for all your static application content.
  • Firewalls provide a boundary to help keep intruders out while your web application operates smoothly.
  • Load Balancers allows configurability and flexibility to manage the traffic and resource usage of server nodes in your environment so that no single device gets overwhelmed.
  • The Web App Server component is the heart of your web application, serving up your core application to end users. Build your server infrastructure using high performance containers, virtual machines, or Cloud Foundry-based runtimes, all of which can be similarly integrated across the architecture.
  • The User Registry Services enable authorization and authentication to secure resources across your application.
  • Session and Data Caching ensure low latency data access and prevents data loss for a robust end-user experience. Additionally, Storage services allow you to customize and have total control over a SAN or NAS solution that fits your storage needs.
  • Managed Database Services deliver high-performance database support, while allowing you to focus on your application and not database maintenance. These databases range from standard SQL databases to newer NoSQL databases to Big Data services.
The above referenced architecture has multiple tiers and multiple components in each tier that are critical to the optimal performance of your web application. The Workshops will specifically focus on the Web and Service tiers, with the Web App Server, Cache, and Load Balancer components. There are some general ground rules that are best followed when developing, deploying, and maintaining Cloud applications, in addition to the above reference architecture. These top 9 rules are covered in detail by Kyle Brown & Mike Capern in a blog post titled Top 9 rules for cloud applications, but we will review them here. First, do not code your application directly to a specific topology. As you can see here, we are only talking about components so far. There is no mention of specific hardware, software, or hosting capabilities. The key here is to keep your application flexible. The second, third and fourth rules all center around the ephemeral, or non-permanent, natures of Cloud applications. Do not assume the local file system is permanent. Do not keep session state inside your application. Do not log to the file system. Many runtimes powering Cloud applications today are ephemeral, or non-permanent. Therefore the application instances and their underlying filesystems can disappear and be rewritten when the application scales or an instance is restarted. Overall, these are not new concepts for web applications, but they are critical for successful Cloud applications. The fifth and sixth rules focus on infrastructure and what you are building your application on. Do not assume any specific infrastructure dependency. Do not use infrastructure APIs from with your application. You do not want to tie your application to the infrastructure it is running on, as it may be moved to another platform by you or the hosting provider, it may run on multiple platforms at the same time, platform APIs and dependencies change at a different lifecycle than your application code and there is no need to add another requirement. It is best practice to abstract the infrastructure needs outside of your application and handle them through management and operation interfaces available on the Cloud platform. The seventh and eighth rules are common across application development to keep your long term sanity. Do not use obscure protocols. Do not rely on Operating System-specific features. You do not know which services your application will need to integrate with in the future. You do not know which operating system your application will run on. Use as many standards-supported APIs as possible when developing your application, so as not to lock yourself into a certain runtime. Finally, the ninth rule. Do not manually install your application. Automate, automate, automate. Whether in development, test, staging, or production, you will want to automate your application installation as much as possible. This will promote reuse, save time, and vastly reduce errors in the long run. That means better application quality and more uptime for users. Hopefully, you are already adopting many of these rules in your applications today. If not, you can read Kyle & Mike’s blog post for more broader detail on what and how to accomplish these goals. The exercises we will be walking through in the Workshops will exemplify these rules and demonstrate capabilities to deliver Cloud applications following them. If you’re ready to get started, lets dive into the first workshop.

Workshop tasks

Arch-Ref-Diagram-Etherpad-Lab1

Task 1. Set up your Bluemix account

IBM Bluemix is an open-standards, cloud-based platform for building, managing, and running all types of applications: mobile, smart devices, web, and big data. The Bluemix capabilities include Java™, mobile back-end development, application monitoring, and features from ecosystem partners and open source, all through an as-a-service model in the cloud. Before you can use the Bluemix capabilities, you must register for an account. Sign up at no charge at and you will have a 30-day free trial. After the 30-day free trial, you will need to provide a credit card to pay as you go for your resource usage. After you sign up, you can find helpful information in the overview section of the Bluemix Docs. Tip: If you are using a free or Trial account, you have a limit of 4 service instances. During subsequent Workshops, you will create a number of service instances for use with the application. You may need to delete some unused or irrelevant service instances to proceed throughout the following Workshops if you’ve already created other services during previous Bluemix activity. To do so, from the Bluemix Dashboard, highlight the settings icon in the top right of the service panel and select Delete. If you are asked to restage your application, click Restage and wait for your application to be redeployed before proceeding.
  1. Log in to Bluemix. The dashboard opens as shown:
    Bluemix Dashboard
    Bluemix Dashboard
    The dashboard shows an overview of the active Bluemix space for your organization. By default, the space is dev and the organization is the project creator’s user name. For example, if bob@example.com logs in to Bluemix for the first time, the active space is dev and the organization is bob@example.com. If you create more organizations or spaces in Bluemix, be sure to use the same ones as you follow the Workshops. Use the default selections.
  2. Create an IBM Container. In the left navigation, select CONTAINERS.
  3. Click CREATE A CONTAINER.
  4. If you are prompted to specify a name for your image registry URL, you must specify it only once. This URL is used to access your private container images from the command line interface. Tip: The registry URL that you enter will be used by your organization when issuing command-line requests with the IBM Containers Extension. Make sure that the registry name that you provide is descriptive and unique, but easy to type.
  5. Now you can see your container launch view. In this view, you can see your registry URL, containers, and images. You will need to use this information later, when you build and deploy containers for your app.

Task 2. Install development tools on your workstation

Next, you will need to install a few development tools on your workstation: Git, Python, pip, Docker, Cloud Foundry CLI, and the IBM Containers Extension (ICE) command line tools.

Installing development tools on Windows 7 and Windows 8

Running Docker on Windows workstations usually requires some trial and error. It may be easier to either obtain a new machine (real or virtual) running Ubuntu 14.04, or run Ubuntu as a virtual machine on top of your Windows operating system. Once you have Ubuntu running, the rest of the setup is straightforward. Windows systems often have virtualization support turned off in the BIOS. Boot to your BIOS settings screen and ensure that you enable virtualization support, or you will not be able to run Docker or any other virtual machine. The virtualization settings will usually show up under the “Security”, “Chipset”, or “Processor” menus. If you have Ubuntu available, you can stop here and follow the Linux setup instructions instead.

Install development tools on Mac OSX

Our suggested setup for Mac workstations is that you run a tool called boot2docker that will run a Linux virtual machine on your workstation. That boot2docker virtual machine is where you will run the Docker containers. Follow the setup instructions here. This will install Git, VirtualBox, boot2docker, Docker, Python, Pip, Cloud Foundry CLI, and the ICE command line tools.

Install development tools on Linux (such as Ubuntu, Red Hat)

Linux workstations (Ubuntu, Red Hat, etc.) can run Docker natively, so you will not need the boot2docker virtual machine. Following the instructions below will setup and configure your development environment in an Ubuntu-based environment. If any issues are encountered, the original links are available after the steps for the specific tools being installed.
  1. Install Ubuntu, either Server or Desktop. Make sure it is the 64-bit version, as Docker requires a 64-bit environment.

    Installation notes:

    • The version used for this workshop was Ubuntu 14.04 LTS.
    • If you are running Ubuntu in a virtual machine and are familiar with networking between hosts and guests, Ubuntu Server is an ideal choice. If you prefer not to configure networking and port-forwarding, Ubuntu Desktop may be an optimal choice to work in a desktop-based environment without having to configure networking on your virtualization platform.
    • You will need to install Docker, Git, Cloud Foundry CLI, and IBM Container Extensions CLI when performing the following steps:
  2. From an terminal window, perform the following commands. These assume you are running as a non-root user (which is common). If you are running as root, you would not need the sudo command at the beginning of each command below. Install Git:
    sudo apt-get install git
    Install Docker-maintained packages:
    sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9
    sudo sh -c "echo deb https://get.docker.com/ubuntu docker main > /etc/apt/sources.list.d/docker.list"
    sudo apt-get update
    sudo apt-get install lxc-docker
    source /etc/bash_completion.d/docker
  3. Test the install of docker using the following:
    sudo docker run -i -t ubuntu /bin/bash
    This will start an Ubuntu-based Docker container and put you in the command line of that running container. If you see a prompt similar to root@4656f27df98f:/#, you can type exit to return to the Ubuntu command line and stop the container instance.
  4. Install Python Indexing Project (PIP) using the following:
    sudo apt-get install python-pip
  5. Install Python Setuptools using the following:
    wget https://bootstrap.pypa.io/ez_setup.py -O - | sudo python
  6. Install Cloud Foundry CLI using the following: Download the latest installer for Debian 64-bit from the release site. Then cd to the directory where you downloaded to and do the following:
    sudo dpkg -i cf-cli_amd64.deb
  7. Install IBM Container Extensions (ICE) CLI using the following:
    wget https://static-ice.ng.bluemix.net/icecli-2.0.zip
    sudo pip install icecli-2.0.zip
Important: ICE may complain that it cannot find Docker or that the ~/.ice/ice-cfg.ini file does not exist. If you get this message, you need to create a ~/.ice/ice-cfg.ini file with the following content and it should resolve the issue. Additional necessary parameters will be added as you interact with ICE.
[DEFAULT]
docker_path = /usr/bin/docker

Task 3. Obtain the sample code

Next, you will need to download the sample code for this workshop from our Git repository. We’ll be using an open-source Node.js application called Etherpad. It’s easy to set up and fun to play with. From here onward, the workshop instructions assume an Ubuntu-based command line environment. Adjust your commands for any alteration in your setup.
  1. Open a terminal window and create a working directory such as “git”, then change into it:
    mkdir git
    cd git
  2. Download our Git repository to your working directory like this:
    git clone https://hub.jazz.net/git/osowski/etherpad-lite
  3. Now change into the etherpad-lite subdirectory you just created:
    cd etherpad-lite
Now you are ready to build the sample application.

Task 4. Build the image for the application

The etherpad-lite directory contains a file named Dockerfile. You can open it in an editor to see what it’s doing, but you won’t have to edit it for this workshop. The Dockerfile tells Docker how to build an image for the container that will run our application: what base image to use (an IBM Node.js container), and what commands to run to install and run the application. Inside the Dockerfile Here are a few interesting parts of the Dockerfile:
  • The first line, starting with the keyword from, tells Docker which container base image to use:
    from registry.ng.bluemix.net/ibmnode:latest
    To learn more about the IBM Node container image, see here.
  • Next, there are several lines starting with run that install the Etherpad application and any packages it needs to run. The base image we are using uses the Ubuntu 14.04 operating system, so the run commands are Ubuntu-style.
    # Install etherpad-lite
    RUN mkdir /src
    RUN git clone https://github.com/ether/etherpad-lite.git \/src/etherpad-lite --branch develop --single-branch
    ADD ./settings.json /src/etherpad-lite/settings.json
    RUN /src/etherpad-lite/bin/installDeps.sh
    EXPOSE :9080
    ENTRYPOINT ["/src/etherpad-lite/bin/run.sh", "--root"]
  • The line starting with ADD copies the settings.json file from the current working directory to the container image. This file was extracted from our GIT repository, along with the Dockerfile:
    ADD ./settings.json/src/etherpad-lite/settings.json
  • Next, the Etherpad installer is run within the container, and tells the container that you will need to access port 9080 using the EXPOSE keyword:
    RUN /src/etherpad-lite/bin/installDeps.sh
    EXPOSE :9080
  • Finally, the ENTRYPOINT line tells the container what command to run at startup to start the Etherpad web application. By adding this line, ensure that Etherpad will be running when you start up your containers:
    ENTRYPOINT ["/src/etherpad-lite/bin/run.sh", "--root"]

Configure the application

The settings.json file in the etherpad-lite directory configures the Etherpad application. The Bluemix containers documentation states that “The only open ports for Containers and your floating IP address are: 22, 80, 443, 9080, and 9443.” This means that you need to configure Etherpad to use port 9080 instead of the default port. We only changed the settings below to get Etherpad running in Bluemix, but you can try changing more settings later:
// Name your instance!
"title": "Etherpad on Bluemix",
//IP and port which etherpad should bind at
"ip": "0.0.0.0",
"port" : 9080,
You can find the source code and documentation for Etherpad on GitHub. Now that we’re familiar with the files, you can build the Docker container.

Build the container

On Linux, you will normally need to start the IBM Containers Extension (ICE) commands below with sudo ice. On Mac OSX, you should not use the sudo command. First, log in to the ICE command line tool:
ice login
Build your container using the following commands in succession, from the etherpad-lite directory. You will need to use the value of your own Registry URL in the following commands. Your Registry URL is listed on the container launch view you saw while setting up your Bluemix account. The first command issued will pull the latest official IBM Node.js container from the global IBM repository.
ice --local pull registry.ng.bluemix.net/ibmnode:latest
The second command builds your application container, and pulls the pulled latest image and with our Dockerfile and settings.json that were extracted from the workshop’s GIT repository. The -t parameter provides a tag that will automatically be applied to the built image, so you can reference it locally. Tip: The trailing period (.) is important to make sure you specify the current directory (the cloned etherpad-lite directory) is the working directory for Docker to build our image from.
  • Format:
    ice --local build -t YOUR_LOCAL_IMAGE_NAME .
  • Example:
    ice --local build -t etherpad_bluemix .
The final command tags your image into a repository with a format that allows you to publish your built image to Bluemix and run it on the IBM Containers service. This command takes your local image that was tagged previously during the build command and applies a repository-specific tag to it, so it can be correctly placed in the IBM Container Service shared repository. This format is required and you will not be able to successfully push an image to Bluemix if you use another image name format that does not match.
  • Format:
    ice --local tag -f YOUR_LOCAL_IMAGE_NAME registry.ng.bluemix.net/ YOUR_REGISTRY_URL / YOUR_REMOTE_IMAGE_NAME
  • Example:
    ice --local tag -f etherpad_bluemix registry.ng.bluemix.net/bluemix_residency/etherpad_bluemix
Your local and remote image names do not have to be the same, but it does help for clarity when comparing local and remote image lists. Also, you can tag your initial image with the full repository tag during the build step instead, but it helps to use shorter tags when running locally to save time and apply the Bluemix-required format before pushing your image to Bluemix. In order, these commands would appear as follows, replacing the necessary formatted parts with your organization and images information:
ice --local pull registry.ng.bluemix.net/ibmnode:latest
ice --local build -t etherpad_bluemix .
ice --local tag -f etherpad_bluemix registry.ng.bluemix.net/bluemix_residency/etherpad_bluemix

Task 5. Test the application on your workstation

Now that your container is built, you can try testing your Etherpad web application locally.
  1. Start a Docker container and run Etherpad in it by entering the following command. The command also prints out a container ID (CID) that you will need for the next step:
    docker run -d -p 9080:9080 etherpad_bluemix
  2. Find the URL to type into your browser to see the running Etherpad web application by entering the following command. Replace ${CID} with the container ID from the docker run command in the previous step. This command provides the IP address of the Docker container itself, which is needed if you are running in a Linux Desktop environment:
    docker inspect --format '{{ .NetworkSettings.IPAddress }}' ${CID}
  3. If you are running a Linux Server environment inside a virtual machine, you must configure port-forwarding for your virtualization platform to access Etherpad running on the container from your host machine. Port-forwarding configuration varies from platform to platform, but forwarding port 9080 on your host machine to the internal virtual machine guest is usually all that is needed. An example of a VirtualBox Port Forwarding configuration is shown here:
    Port Forwarding Rules
    Port Forwarding Rules
    Similarly, a virtual machine running on VMWare would require a port forwarding rule as well, but the Guest IP value would be the IP address associated with the VMWare 8 network. On Mac OSX, boot2docker is running Docker in a virtual machine, so you need the IP address of boot2docker (usually 192.168.59.103). Run this command to get the IP address of boot2docker:
    boot2docker ip
  4. In this workshop, you are hosting Etherpad on port 9080, so to test your running Etherpad application you can open a URL like this in your browser (replacing 192.168.59.103 with your container’s IP address): http://192.168.59.103:9080/ If everything is running correctly, you’ll see a welcome screen:
    New Pad window
    New Pad window
  5. Go ahead and create a new Pad and play around with it. This simple Etherpad setup uses a local file to store the Pad text, so data does not persist across containers. Therefore, your Pads and text are deleted when you shut down the container. In Web application hosting with Database Services, you will configure Etherpad to use a real database hosted in Bluemix, so that you can save your data.

Task 6. Run the application in Bluemix

After you have the application running locally, you can publish it to a container running in Bluemix and run it on the Internet. Here are the commands to run the container in Bluemix. You will need to replace some values with your environment specific values, so read the formatting of each command before executing them below, in order:
ice --local push registry.ng.bluemix.net/bluemix_residency/etherpad_bluemix
ice images
The ice –local push command publishes the container image to Bluemix and places it in your organization’s registry, scoped by the Registry URL you configured when you created your Container Service instance.
  • Format:
    ice --local push registry.ng.bluemix.net/ YOUR_REGISTRY_URL / YOUR_REMOTE_IMAGE_NAME
  • Example:
    ice --local push registry.ng.bluemix.net/bluemix_residency/etherpad_bluemix
The ice images command will print out the published image URL for you, along with some other data associated with the rest of the images you have pushed up to Bluemix. The output of the ice images command will be similar to below, with the <uuid> fields being actual unique IDs generated for each image pushed to Bluemix:
The output of the ice images command
The output of the ice images command
Note the etherpad_bluemix image that you pushed up to Bluemix with the previous ice --local push command and the difference between its image name and the other two images provided by IBM. As an end user, you can only pull from the base global directory, but you can push to (or pull from) your Organization-scoped repository by using the format in the previous command. Now create a running container instance on Bluemix by issuing the run command:
ice run -p 9080 --name etherpad_01 registry.ng.bluemix.net/bluemix_residency/etherpad_bluemix:latest
You will need to change the container name parameter from etherpad_01 or whatever you choose each time you create a new container. This container name does not have to be scoped with a complete URL like the image name does, as it is only for ease of identification of running containers. It can be a simple string and just has to be unique across the containers you have running inside your Containers service instance. You will also need to replace registry.ng.bluemix.net/bluemix_residency/etherpad_bluemix:latest with your own image URL. The :latest tag at the end of the URL specifies to run the latest version of that image, if multiple exist. Specifying the -p parameter will expose the desired port on the running container inside the Container Service. This parameter needs to be specified for each port you wish to be accessible on your container.
  • Format:
    ice run -p PORT_TO_EXPOSE --name UNIQUE_CONTAINER_NAME registry.ng.bluemix.net/ YOUR_REGISTRY_URL / YOUR_REMOTE_IMAGE_NAME :latest
  • Example:
    ice run -p 9080 --name etherpad_01 registry.ng.bluemix.net/bluemix_residency/etherpad_bluemix:latest
The ice run command will return a unique container ID (CID); use that CID in commands run for that container. In the following examples, the CID is dd489740-ffff-4c8f-9117-d94cd147f122, so replace that with your own CID. Before you can connect to your web application, you will need to assign it a floating public IP address. The ice ip request command will assign one to you. Replace 129.0.0.0 in the example below with the IP address returned from the ice ip request command.
ice ip request
ice ip bind 129.0.0.0 etherpad_01
In this workshop, you’re hosting Etherpad on port 9080, so to test your running Etherpad application you can open a URL like this in your browser (replacing 129.0.0.0 with the IP address returned from the ice ip request command): http://129.0.0.0:9080 / Your account gets only two of these public IP addresses at no charge, so unbind the IP addresses when you’re not using them. Replace 129.0.0.0 in the example below with the IP address returned from the ice ip request command, and replace dd489740-ffff-4c8f-9117-d94cd147f122 with your own CID:
ice ip unbind 129.0.0.0 etherpad_01
If you want to look up the CIDs for your running containers, and your published image names, you can click the Create A Container view of the Bluemix dashboard, or you can use the following ICE commands to view running containers and published images respectively:
ice ps
ice images

Stopping or removing a running container instance on Bluemix

As a best practice, we should stop (and optionally remove) the local containers that were used for testing once the application is running on Bluemix. This can be done by the following commands. First, find the running Docker container instances.
ice --local ps
Next, stop the Docker container instance by container ID, available as output from the previous command.
ice --local stop CID
Finally, to remove the Docker container instance entirely (again, as an optional step — it only needs to be stopped to proceed with future Workshops), use the container ID again as the parameter to the remove command below.
ice --local rm CID
Any locally running Etherpad containers should be stopped at the end of each Workshop for error-free progression through subsequent Workshops.

What’s next?

Continue with the remaining Workshops in this series:

17 comments on"Actionable Architecture: Web application hosting using containers (Etherpad Workshop 1)"

  1. The commnd is boot2docker ip not boot2dockerip

  2. peter keeler March 04, 2015

    Rick, will this work within Devops Services, aka Jazz Hub?

    I’m trying to configure the build but not sure what to select.

    • Rick Osowski March 05, 2015

      Yes, this should work within IBM DevOps Services as well. We’re working on another lab that will add the new capability to this application series. It should be published relatively soon.

  3. I was able to run locally. But after pushing and starting on bluemix and adding the ip, I cannot reach it on bluemix

    Container Id Name Group Image Created State Private IP Public IP Ports

    89751470-4257-49e4-bc76-c7a43910e5da etherpad_01 wlife/etherpad_bluemix:latest Mar 26 18:50 Running 172.16.136.4 129.41.232.208 []

  4. I also do not appear to be able to ssh to it. I put my public keys on it. Do I need to use a special ssh port?
    ssh: connect to host 129.41.232.208 port 22: Connection refused

  5. The “ice run…..” commands in Task 6 probably need to include “-p 9080” so the port is bound to the container when the container is created.

    • Rick Osowski April 03, 2015

      Thanks, Doug. Task 6 has been updated to include the updated requirement for specifying the exposed ports manually when running a container instance on Bluemix.

  6. Regarding “Install development tools on Mac OS X”… the link at the word “here” goes to a page that says “The IBM® Containers documentation has moved. Check out the new content at https://www.ng.bluemix.net/docs/containers/container_index.html.” This new link takes the user to IBM Containers documentation where I do not see any instructions on how to instal “Git, VirtualBox, boot2docker, Docker, Python, Pip, Cloud Foundry CLI, and the ICE command line tools”? Maybe I’m missing something, but is there a web page with instructions to setup a Mac to work with IBM Containers and this tutorial?

  7. This tutorial no longer matches the Bluemix dashboard. I’m not certain which container image to select or whether I choose add my own…

  8. I keep receiving the following error for Task 4, Build the Container. I execute “ice login” and I get the following:

    “Proceeding to authenticate with the container cloud registry at registry-ice.ng.bluemix.net
    Cannot connect to the Docker daemon. Is the docker daemon running on this host?
    docker is not available on your system or is not properly configured
    Could not authenticate with cloud registry at registry-ice.ng.bluemix.net
    You can still use IBM Containers but will not be able to run local docker containers, push, or pull images”

    When I execute “ice –local pull registry.ng.bluemix.net/ibmnode:latest” I receive the following error:

    “Target is local host. Invoking docker with the given arguments…
    Cannot connect to the Docker daemon. Is the docker daemon running on this host?”

    But when I run “sudu service docker status” I get:
    “docker start/running, process 5718”

    Meaning the daemon is running…no?

    Any help would be appreciated.

  9. Helmut Tammen February 09, 2016

    When I try to pull the IBM node image in task 4 I get the following error.
    Tried it on my Mac as well as in a docker container like mentioned in Option 1 here: https://www.ng.bluemix.net/docs/containers/container_cli_ice_ov.html

    root@6b347e665cb8:/git/etherpad-lite# ice –local pull registry.ng.bluemix.net//ibmnode:latest
    Target is local host. Invoking docker with the given arguments…
    Error response from daemon: Get https://registry.ng.bluemix.net/v2//ibmnode/manifests/latest: no basic auth credentials

    Any hints?

    • Helmut Tammen February 09, 2016

      Found the problem. Cause my registry is located in UK I have to login with that registry

      ice login -R registry.eu-gb.bluemix.net

    • Helmut Tammen February 09, 2016

      When I try to push to bluemix (task 6) with the following command:
      ice –local push registry.eu-bg.bluemix.net//etherpad_bluemix

      I get the following error

      Target is local host. Invoking docker with the given arguments…
      The push refers to a repository [registry.eu-bg.bluemix.net//etherpad_bluemix]
      unable to ping registry endpoint https://registry.eu-bg.bluemix.net/v0/
      v2 ping attempt failed with error: Get https://registry.eu-bg.bluemix.net/v2/: x509: certificate is valid for *.bluemix.net, bluemix.net, not registry.eu-bg.bluemix.net
      v1 ping attempt failed with error: Get https://registry.eu-bg.bluemix.net/v1/_ping: x509: certificate is valid for *.bluemix.net, bluemix.net, not registry.eu-bg.bluemix.net

      Any hints?

Join The Discussion

Your email address will not be published. Required fields are marked *