Compute Services

New deployment architecture for IBM Containers

Share this post:

As of May 23rd IBM Bluemix Container Service now provides a native Kubernetes operations experience while removing the burden of maintaining master nodes. Kubernetes itself is based on the Docker engine for managing software images and instantiating containers. Get the details.


We are excited to announce several new capabilities in IBM Containers for Bluemix. The IBM Containers architecture provides enhanced availability of the public cloud offering. New users and new spaces for existing users are running in this environment automatically beginning April 11, 2016.

Here are some of the new features that are enabled:

  • Faster time to live for new containers and container groups
  • Improved Performance of API calls
  • Higher performance ephemeral disk
  • Simplified, more resilient network architecture
  • Support for Docker engine 1.10
  • Docker Registry v2
  • Access to container groups over the private network
  • Native Docker Compose support (version 1.6.0 or later)
  • Auto-scaling container groups (coming later in Q2, stay tuned!)
  • VPN service
  • URL route mapping across spaces

How might this announcement affect you?

New users and new spaces for existing users are running in this environment automatically beginning April 11, 2016; other users will be need to be migrated.

What are your migration options?

If you created your space in Dallas before April 11 or London before April 25, you can choose to start using these new capabilities immediately or you can wait for it to be migrated for you. Use the following steps to start using these services immediately:

Option 1: If it is acceptable for your service to be down temporarily, we have a new Containers CLI feature to help with your migration. The time for this command to run is proportional to the amount of containers in your current space. For this reason, it could take up to 20 minutes.
NOTE: With this option, your existing Bluemix services will remain deployed in a given space. Your IP addresses will not migrate and you will have new addresses. Containers will not be re-deployed automatically. Some services may require additional configuration. Specifically, the VPN Service instance will show as deployed, it will need to be deleted and a new instance will need to be re-created and re-configured after creating containers in the re-provisioned space.

  1. Log into the CLI using your IBM Bluemix account.
    • Execute “cf login” to login to IBM Bluemix
    • Execute “cf ic login” to login to IBM Containers
  2. Ensure you are using version 874 or later of the Containers CLI Plugin
    • Execute “cf plugins” to verify
    • Execute “cf ic update” to get the latest version
  3. Execute “cf ic reprovision” for each space in your organization
    • You can switch spaces with “cf spaces” and “cf target -s ”
  4. Execute “cf ic info” and ensure you see “prod-dal09-kraken1″ for the Environment Name
  5. If you do not see “prod-dal09-kraken1″, execute “cf ic reprovision” a second time before contacting IBM support.
  6. If you have VPN service configured in your space prior to migration, please delete the current VPN instance, then after you migrate to new architecture and create the containers, please ensure you re-provision the VPN service by going to the Catalog -> Services -> Network -> Virtual Private Network Service.

Option 2: If you are using container groups and need to maintain 100% uptime. use the following steps, note that your existing space is noted as SpaceA, your new space is noted as SpaceB:
NOTE: With this option, your existing Bluemix services will require a redeployment in the new space. Your IP addresses will not migrate and you will have new addresses.

  1. Log into the CLI using your IBM Bluemix account.
  2. Create SpaceB within your Bluemix organization. Validate you are using the new offering by:
    • Using the Cloud Foundry CLI to login to the Dallas environment and target your new space (see IBM Containers documentation for more details)
    • Execute “cf ic login”
    • Execute “cf ic info” and ensure you see “prod-dal09-kraken1″ for the Environment Name
  3. Ensure you update the distribution of your quota to SpaceB. From the IBM Bluemix UI, update your account settings select Manage Organizations -> Quota -> Containers and adjust the quota settings for SpaceB. If you do not have an edit button to perform this action, your quota allotment does not support this manual migration. You may use the above CLI migration method or contact Chris Rosen (crosen@us.ibm.com) so that we can assist with the remaining steps.
  4. (Optional) If your existing container group in SpaceA is using Bluemix services you will need to follow these steps to get the connection information for these services to use in SpaceB container groups
    • Execute “cf ic inspect <SpaceA group name>” to get a list of all environment variables. You will need to take note of all of the “VCAP_SERVICES_*” variables as you will need to manually pass all of these into your SpaceB container group.
    • You will also want the full VCAP_SERVICES json which is available via the IBM Bluemix UI. If you navigate to your SpaceA container group and then go to the Connections tab and click on View Credentials for you attached services you can get the json that you will want to pass into your new SpaceB container creation. Note that you will need to escape (\”) and double quotes from this data.
    • An example of a group create using this would be: “cf ic group create –name myspacebgroup -e “VCAP_SERVICES_TONE_ANALYZER_0_METADATA_URL=https://api.ng.bluemix.net/v2/service_keys/XXXX” -e “VCAP_SERVICES_TONE_ANALYZER_0_LABEL=tone_analyzer” -e “VCAP_SERVICES_TONE_ANALYZER_0_CREDENTIALS_URL=https://gateway.watsonplatform.net/tone-analyzer-beta/api” -e “VCAP_SERVICES_TONE_ANALYZER_0_CREDENTIALS_PASSWORD=XXXXXX” -e “VCAP_SERVICES_TONE_ANALYZER_0_NAME=Tone Analyzer-nk” -e “VCAP_SERVICES_TONE_ANALYZER_0_PLAN=beta” -e “VCAP_SERVICES_TONE_ANALYZER_0_CREDENTIALS_USERNAME=XXXXX” -e “VCAP_SERVICES_TONE_ANALYZER_0_ENTITY_SERVICE_INSTANCE_URL=https://api.ng.bluemix.net/v2/service_instances/XXXX” -e “VCAP_SERVICES={\”Tone Analyzer\”: [{\”name\”: \”Tone Analyzer-nk\”,\”label\”: \”Tone Analyzer\”,\”credentials\”: {\”url\”: “https://gateway.watsonplatform.net/tone-analyzer-beta/api\”,\”password\”: \”XXXXX\”,\”username”: \”XXXXX\”}}]}” –desired 2 –port 9080 registry.ng.bluemix.net/ibmliberty
  5. If you are using container volumes you will need to tag any volumes in SpaceA for availability in SpaceB
    • Execute “cf target -s SpaceA”
    • Execute “cf ic login”
    • Execute “cf ic volume space-add VOLUME_NAME SpaceB” to give SpaceB permission to use the volume owned by SpaceA
  6. Deploy your container group in SpaceB using the same images from your image registry in the organization. You can use the same public URL route for your container group that you were using in SpaceA to avoid disruption in the service.
    • Execute “cf ic route map -h [host name] -d mybluemix.net [new container group name/id]”
    • Traffic will be round robin balanced across both container groups from the original space and the new space.
    • Unbind the route from the SpaceA container group
  7. Once the new group is up, you can then run “cf ic reprovision” for SpaceA and stand your original groups up again in this space. Optionally, you can then tear down SpaceB.
  8. If you have VPN service configured in your space prior to migration, please delete the current VPN instance, then after you migrate to new architecture and create the containers, please ensure you re-provision the VPN service by going to the Catalog -> Services -> Network -> Virtual Private Network Service.

On May 25, 2016, we will migrate any remaining Bluemix spaces that were created before April 11th. After this migration, you will not lose any images that were hosted in your private registry or any deployed Bluemix services. However, your running containers will not be migrated and will need to be re-deployed. Your existing public IP addresses will not migrate and, therefore, you must reconfigure any external DNS configurations that are using those IPs.
If you have VPN service configured in your space prior to migration, please delete the current VPN instance, then after you migrate to new architecture and create the containers, please ensure you re-provision the VPN service by going to the Catalog -> Services -> Network -> Virtual Private Network Service.
You will not be billed for containers once IBM deletes them as part of the space migration and the org quota will not be affected.

Add Comment
2 Comments

Leave a Reply

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


Leo Kenji

sounds great, thx!

Reply

crosen

Attention UK users, please look for the roll-out in London on Monday, April 25th!! Thanks for your patience.

Reply
More What's New Stories

Financial transaction compliance made easy with Yantra

Yantra transformed into an award winning Fintech powerhouse. Yantra Financial Technologies was recognized as a “Company to Watch” as part of the 2016 FinTech Forward rankings released by American Banker and BAI.

Continue reading

Docker EE Comes to the IBM Cloud

Today, IBM and Docker announced plans to deliver Docker for IBM Cloud a joint solution offering from IBM and Docker Inc. available as a beta in 4Q 2017.

Continue reading

IBM Cloud Activity Tracker – go live with new features

Starting today, IBM Cloud Activity Tracker is generally available with new service plans in the US South region. IBM Cloud Activity Tracker allows you to view, manage, and audit cloud activity events in the IBM Cloud. The service can be found under the Security and DevOps sections of the Bluemix catalog.

Continue reading