A few months ago we developed some functionality based on an unsupported non-production-ready service.
Unsurprisingly we are now in the process of re-writing the functionality to use a real implementation.
Hot tip for reducing the amount of time to deliver a software project - don't build on something that isn't going to exist when your system will be going live.
Coincidentally we have moved away from inserting fake data into our databases in development, QA and production environments. Fake data doesn't belong in our live systems.
Our application doesn't need to insert data into the system, so we no longer need our data access permissions to have inappropriate permissions.
Tuesday, 2 December 2014
Wednesday, 12 November 2014
Docker Hub Group permissions
As part of a story in a recent development iteration at work, I found myself guiding two development teams in the use of Docker Hub.
Strangely my current project had already had an indirect dependency on Docker Hub for a few months, but today was the first time that we actually needed to consider the ins and outs of this particular system.
In this case the "in" side involves our continuous deployment system pushing an image, and the "out"side involves a separate system pulling an image from the same repository.
In the interests of ensuring that each project team does not run the risk of accidentally blowing away anything or everything that the other project teams have set up, I took it upon myself to learn the ins and outs of group permissions in Docker Hub.
Now instead of just having one big group of Owner users associated with our organisation we have two additional groups for my current project - one that contains users with the right to push images, and one with the right to read (pull) images.
Strangely my current project had already had an indirect dependency on Docker Hub for a few months, but today was the first time that we actually needed to consider the ins and outs of this particular system.
In this case the "in" side involves our continuous deployment system pushing an image, and the "out"side involves a separate system pulling an image from the same repository.
In the interests of ensuring that each project team does not run the risk of accidentally blowing away anything or everything that the other project teams have set up, I took it upon myself to learn the ins and outs of group permissions in Docker Hub.
Now instead of just having one big group of Owner users associated with our organisation we have two additional groups for my current project - one that contains users with the right to push images, and one with the right to read (pull) images.
Monday, 10 November 2014
Strange day in the office
My plan to wait for other teams to sort out the approach to deploying applications in Docker didn't work out quite the way I had hoped.
This morning I guided some colleagues to get our application set up to run from a Docker image, without worrying about the details of deploying anywhere - expecting that another development team would have that sorted out from their project first.
Sure enough, come mid-afternoon we'd established that the other development team didn't need that functionality yet so we'd have to figure it out for ourselves.
Okay, we have a tools engineering team that have already provided something Dockerised automagically through Dockerhub so they'll be able to show us how to do it in no time.
It turned out that the approach used so far involved Dockerhub pulling the Docker image content directly from a Git repository. This doesn't quite suit our needs, as our application needs to be built from source first.
The ugly option involved setting up a dedicated Git repository for our binary artifact, which Dockerhub could pull across.
Back to the drawing board.
An hour or so later I overheard my colleagues mentioning something about authenticating to Dockerhub from Gradle. It turns out that the plugin they've used for creating a Docker image can also be applied to push to a Docker repository.
Don't worry, there's more fun ahead to get this set up in the continuous deployment pipeline.
This morning I guided some colleagues to get our application set up to run from a Docker image, without worrying about the details of deploying anywhere - expecting that another development team would have that sorted out from their project first.
Sure enough, come mid-afternoon we'd established that the other development team didn't need that functionality yet so we'd have to figure it out for ourselves.
Okay, we have a tools engineering team that have already provided something Dockerised automagically through Dockerhub so they'll be able to show us how to do it in no time.
It turned out that the approach used so far involved Dockerhub pulling the Docker image content directly from a Git repository. This doesn't quite suit our needs, as our application needs to be built from source first.
The ugly option involved setting up a dedicated Git repository for our binary artifact, which Dockerhub could pull across.
Back to the drawing board.
An hour or so later I overheard my colleagues mentioning something about authenticating to Dockerhub from Gradle. It turns out that the plugin they've used for creating a Docker image can also be applied to push to a Docker repository.
Don't worry, there's more fun ahead to get this set up in the continuous deployment pipeline.
Wednesday, 22 October 2014
Degrees of freedom in software
One of my current projects involves developing a new application to act as a backend setup service.
For licensing reasons this particular application cannot be deployed into our cloud environment - so I've been evaluating what options are open from various perspectives.
For licensing reasons this particular application cannot be deployed into our cloud environment - so I've been evaluating what options are open from various perspectives.
- Operating System
- Fixed to the same as other services running from the same machine.
- Language level
- Possibly tied to the same as existing applications - unless we can tweak chef provisioning to support multiple versions (maybe simple?).
- Application server
- Hopefully completely flexible, which should allow us to use the embedded approach.
- Dependency injection framework
- Hopefully completely flexible, although the main library dependencies are very Spring oriented.
- Slight preference for UtterlyIdle as that matches the other components.
- UPDATE: Due to the tight coupling of a third party library, a selection of Spring framework dependencies are bundled in the application and will be required at runtime.
- Build system
- Relatively flexible, but easiest with something that plays nicely with dependency management - leaning towards Gradle rather than Maven.
- Continuous Integration and deployment
- Need to decide between Go and Jenkins.
- Likely to involve scp and shell scripts.
- Monitoring and logging
- Although this environment will have easier file system access than our cloud setup we should log to the logging service.
- We could expose JMX profiling for monitoring of memory usage etc. on our internal monitoring infrastructure.
Wednesday, 10 September 2014
.london domain name
After living in London for almost six years, I'm now on my very own .london domain name.
Tuesday, 26 August 2014
Running Docker on Mac
Tonight's mission - get an application from the day job up and running on one of my Macs at home...
So, Docker is designed to run on top of a Linux kernel - which Mac OS X obviously doesn't offer.
A quick Google leads to:
http://docs.docker.com/installation/mac/
which directs me to Boot2Docker :
https://github.com/boot2docker/osx-installer/releases
Open the downloaded package and double click to install the VM image
Binaries are now on the path and ready to run from a command line terminal:
> boot2docker init
> boot2docker start
Then the top secret bit for pulling down the Dockerised application...
Tweak the configuration properties to use the newly created Docker host instead of the hand-coded Linux environment's Docker configuration (host IP address).
Run the application's tests.
Let out a satisfied "Aaah" or "Mmm" (optional).
This all took about 20 minutes, but most of the time was spent waiting on downloads.
So, Docker is designed to run on top of a Linux kernel - which Mac OS X obviously doesn't offer.
A quick Google leads to:
http://docs.docker.com/installation/mac/
which directs me to Boot2Docker :
https://github.com/boot2docker/osx-installer/releases
Open the downloaded package and double click to install the VM image
Binaries are now on the path and ready to run from a command line terminal:
> boot2docker init
> boot2docker start
Then the top secret bit for pulling down the Dockerised application...
Tweak the configuration properties to use the newly created Docker host instead of the hand-coded Linux environment's Docker configuration (host IP address).
Run the application's tests.
Let out a satisfied "Aaah" or "Mmm" (optional).
This all took about 20 minutes, but most of the time was spent waiting on downloads.
Subscribe to:
Posts (Atom)