Part Two.. Installing team city into Rancher via docker hub
Note : If you’ve reached this page directly, it’s advised to complete part one of tutorial. Part one covers creating the environment needed to begin deployment of your first container. The installation of process of teamcity once running is also not covered.
Although containers can be installed directly onto hosts I’d advise working at the service level. Services allow more advanced rules for provisioning to be applied and generally make day to day activities easier.
The first part of the process is creating a stack. A stack can contain a range of container types and instances.
I called mine “ContinuousIntegration”
This is how eventually how your stack will look. In order to create the server click “Add Service”.
Creating a service looks something like this :
- Give the service a sensible name.
- “Select Image” needs to be set to “aerofs/teamcity”
- Ensure port 8111 is open on both public host and mapped to the private container port.
- In the networking tab ensure a hostname is specified you’ll need this later when adding a build agent.
By default no containers will be provisioned click the “Play” button.
Next click the service name to drill into the service and the finally on the container name.
Finally paste the “Host IP” followed by “:8111” into a browser and if all’s well teamcity should appear.
In the next part I’ll cover provisioning a build agent.
What is technical debt?
Technical debt (also known as design debt or code debt) is a recent metaphor referring to the eventual consequences of any system design, software architecture or software development within a code base.
Recently I’ve been hearing the phrase used much more often, sometimes it’s setting the scene by a developer before a rushed fix is put into place, or how poor code is explained in a system. I accept this as part of software development but hearing this phrase from non technical people causes me concern.
Is this acceptable? Hearing that it’s OK to incur technical debt to deliver a project early I think not. Debt used to be a word that had respect, folks didn’t want debt but a change in attitude with a pay it back later mentality is something people are more comfortable with in the modern world.
In my experience the intention is always to return and pay it back, but rarely does this happen. The realisation of reducing the ability to deliver change to a customer base isn’t acceptable. But just like any debts the issue compounds until it’s unmanageable.
Working on a code base full of technical debt is uninspiring and saps the life out of all that surround it, and once it’s acceptable to allow the debt more will almost always follow.
Don’t be afraid to re-factor and redesign, sometimes it will punch you in jewels but learn, embrace and improve. Working within an environment that holds these values close breeds a sense of ownership and pride and ultimately promotes good practice to all.
Without debt holding change back, delivery will flourish and accomplishment will bring pride and courage.