Today we’re announcing a few immediate changes, as well as some other changes you should expect over the next couple of months.
The tl;dr here is that we’re launching a slight change to how containers are networked on Codeship Pro. In most cases, this won’t impact your builds…but it is the first step toward things like the
depends_on directive and healthchecks that will be great additions.
While these are not available yet, please get in touch with us if you want beta access once they are.
[Tweet “”We’re launching a slight change to how containers are networked on Codeship Pro” via @codeship”]
What We’re Releasing
As of today, we will begin rolling out a change to Codeship Pro to run all containers on isolated networks per-step. We have been testing this for several weeks and expect to have this change rolled out to all customers by January 9th, with new customer segments being added each day until then. This shouldn’t be breaking behavior for any builds, but it does provide three new behaviors that are good to know about:
- Containers are now discoverable bidirectionally without workarounds. This means all containers on the network can see all containers on the network regardless of linking or dependent order.
- We are formally deprecating host port mapping at the end of January. You’re most likely not doing this, as we have not formally supported it in the past and it would have caused issues with any parallel steps you were running — but you will now see a notice in your logs announcing that if you are mounting a host port, it will need to be removed.
- Services will not be able to communicate with other parallel steps outside of their isolated networks. This means that services like ElasticSearch utilizing multicast or broadcast for service-discovery will not be able to inadvertently cause port conflicts.
Why We’re Making These Changes
So then, why are we making these changes?
codeship-services.yml file is not meant to be a Compose file, we do aim to reuse existing patterns and knowledge where we can to make sure that setting up your CI/CD configuration files is as easy as possible.
To that end, over the next few months we will be introducing both
depends_on and healthchecks support, similar to Compose, and deprecating our links functionality.
To do this, we opted not to take a shortcut and implement it against existing code but instead to take the time to truly build a more forward-thinking foundation for Codeship Pro.
The CLI you may be familiar with for local debugging is the same task runner that also runs your remote builds on Codeship, and we’ve done some serious work on the code that runs that tool.
The deliverable on this leg of work is the networking changes, which fix a few common issues while laying the foundation for links deprecation and the introduction of
depends_on. The less visible work is a heavy bit of refactoring underneath the hood to produce a more stable and higher quality Codeship Pro that will also allow us to build new features faster than ever before.
For the immediate change we are releasing today, you can read the documentation to get a more full sense of how our containers now network by default.
For the technical work we’ve been doing under the hood, we will be rolling out a few blog posts (first one is here!) over the next couple of months going into more detail on the technical specifics of the work we’ve done, what we’ve learned from it, and how we approached building a more solid foundation to work off of.
And keep your eyes peeled for
depends_on and healthchecks, and let us know if you want to be in the beta for these features once they are ready!
[Tweet “”Isolated Networks, Container Discoverability, and Code Upgrades at Codeship” via @codeship”]