There are many reasons to run a web service in a container. One of the remote services I rely on most heavily is git. While git local operations are fine in a global namespace, running a shared git repository on a remote server is a web-service based use case. There are three protocols used most commonly to remotely access git: git, ssh, and https. I am going to focus on the last one here.
Continue readingWhile I was able to read/clone a git repository self-hosted with HTTPD and git-http-backend, I found that I could not push to it. Here’s how I fixed it.
Continue readingWhile local git is fine for personal development, sometimes you want to make stuff happen on a remote machine, either to share or for backup. SSH works well for this. However, I am going to target hosting my Git repository in an OpenShift instance, and HTTPS will be a much easier protocol to support.
Continue readingSome colleagues and I were discussing the network access policy of OpenShift. I realized it would be very helpful to have a trivial app that I could deploy to OpenShift that would then try to make a call to another service. So I wrote it using Python3 and Flask. Now that I have it working, I want to deploy it in OpenShift, again, in a trivial manner.
I would not deploy a Flask App into production without a Web server to front it. But that is what I am going to do for this test app.
Continue readingLabs are designed for learning. I learn by doing. While I can read, as they say in the local vernacular in my propinquity “Wicked Fast,” I don’t process read information to the depth that I need in order to retain it. I need to type in the code in order to learn. Here’s a technique I use to do that.
Continue readingAn earlier port hard coded the IP address and port used for MariaDB connections. I want to pull these out so I can pass them in on the command line when I create the client.
Continue readingCloud is easy. It is networking that is hard.
Red Hat supports installing OpenShift on OpenStack. As a Cloud SA, I need to be able to demonstrate this, and make it work for customers. As I was playing around with it, I found I could not tear down clusters due to a dependency issue with ports.
Continue readingMe. Us. Them.
The story I tell when I explain the various offereings that Red Hat has based on Ansible follow is based on the progression of Me. Us. Them.
Me: Get my playbook working for me on my workstation. For this, I use Ansible Engine.
Us: Share my playbook with my larger team. For this, I use Ansible Tower.
Them: Make a Self service catalog for the larger organization to consume. This is where Ansible integration into other products comes in to play. I typically talk about CloudForms integration here, but Satellite and OpenShift are also capable of making use of Ansible here.
Here is how I have my local setup for doing Ansible based development. This is organized roughly around how Tower will later consume the roles and playbooks I design here.
Continue readingWhen a user requests a code review, the review is responsible for making sure that the code is tested. While the quality of the tests is a subjective matter, their presences is not; either they are there or they are not there. If they are not there, it is on the developer to explain why or why not.
Not every line of code is testable. Not every test is intelligent. But, at a minimum, a test should ensure that the code in a patch is run at least once, without an unexpected exception.