Step by step breakdown of IBM Bluemix image deploy

Step by step breakdown of IBM Bluemix

1) Creating local image

$ ice --local build -t $IMAGE_NAME:$TAG $DIR

The first step of working with Bluemix is to create a local image. This step is analogous to creating an image in Docker. The main difference is that the build produced here can be pushed to the IBM Bluemix cloud repository. Bluemix can connect to Dockerhub, however, it can also host your images privately out of the box, and sync with your local Docker daemon images.

SUPPORT

2) Tag and Push

$ ice --local tag $IMAGE_NAME $REGISTRY_URL/$NAMESPACE/$IMAGE_NAME:$TAG

$ ice --local push$REGISTRY_URL/$NAMESPACE/$IMAGE_NAME:$TAG

The local image is now tagged, and pushed to the IBM Bluemix cloud repository for use to add to a container in the following step.

SUPPORT

3) Create and run container

$ ice run --name $UNIQUE_CONTAINER_NAME $EXPOSED_PORTS $NAMESPACE/$IMAGE_NAME:$TAG

This piece may throw some people off base, and for good reason: "How come is it when I delete a container that I can no longer use that container's name?". Indeed, each time you apply an image to a cloud container, the cloud container needs a unique name that was never used before. Otherwise, you'll soon find that there will be an exception that the container already exists. It's a cloud repository after all. Therefore, assign a new name for a container each time you decide to run this command.

After this step you're done! You can of course, continue either by having access to a public IP address or by making code edits, and having to handle changes thereof.

SUPPORT

4) Access your public IP address if you don't have one already

$ ice ip request

The next step is self-explanatory. I hope you can foresee that you'll then have to assign this IP address to your cloud container for it to do anything useful. You may also derive a public IP address by utilizing the IBM Bluemix GUI instead of the CLI.

5) Bind/unbind IP address to a cloud container

$ ice ip unbind $PUBLIC_IP_ADDR $OLD_CONTAINER_NAME

$ ice ip bind $PUBLIC_IP_ADDR $UNIQUE_CONTAINER_NAME

In case you'd like to bind a public IP address, for instance to access various ports inside your application, you will have to bind them. I have been avoiding to run this step if another container is using the public IP address my clients utilize. This is preceded by unbind or stopping and removing the other container running the application. Of course, be careful when removing your container as it can no longer start. You may keep previous container(s) to revert in case your new adjustments have corrupted your code.

6) Logging

$ ice logs $UNIQUE_CONTAINER_NAME

The ability to log was a paramount concern. In addition to options such as SSH to your container, you can login to your IBM Bluemix from a Docker VM environment, and view your logs in real time.

7) Cleanup

$ ice rm $OLD_CONTAINER_NAME

Let's get rid of the previous, inactive, and unbound container for good measure and housekeeping.

To remove previous images, simply get rid of them from local and cloud

$ ice --local rmi $REGISTRY_URL/$NAMESPACE/$IMAGE_NAME:$TAG

$ ice --local rmi $NAMESPACE/$IMAGE_NAME:$TAG

$ ice --cloud rmi $NAMESPACE/$IMAGE_NAME:$TAG

Check out the BlueImage script for automation of simple deployments outlined above