Gitworkflow and testing short lived feature branches in Openshift/Kubernetes

I'm not altogether sure if there actually is a problem you're trying to solve, or whether you are looking for confirmation that you are on the right track. Some thoughts:

  Internally openshift should be able to allocate dedicated pods

Sure. Add a post-build step in your CI pipeline which does the following:

Fashion a .yaml or .json description of that pod (or rather, DeploymentConfig). How/where you do that depends on your architecture - if each of your microservices has exactly the same port (i.e., all listening on 80 or 443), then you only need a central template for that, and basically only inject the name (containing the microservice name and the feature branch name) and the git source URL for it. The file can of course contain multiple OpenShift objects (i.e., the DeploymentConfig and a Route, maybe).
oc apply it, OpenShift will build an image and start a pod for it.

  and they should be disposed once merged with develop branch

Add a post-merge step which does the same in reverse, i.e. oc delete ... for every component of the original .yaml. Probably this is easiest if you give a branch-based label to each of the components, so you don't need to keep track of which you have applied in the first place.

  another problem with this approach is running integrated test or if services have dependency with consumer apis.

If a service involved in an integrated test has state, then you indeed need to fire up a new pod/volume for each test run. If your integration test depends on external state, then you also need to manage that somehow. Both of these aspects are true anyways, no matter how you architect your solution.

In these cases, you would probably do well to not start deployments right out of your individual CI pipelines, but do a "big" deployment when you start your integration test (i.e., deploy all individual microservices like described above, but also inject an ID for your current integration test run into all their names, so everything stays unique).

  Modifying the service name based on feature branch is not a good idea.

Why not? If you wish to have a pod running for every feature branch, then you need to do it that way, period.

It would certainly force you to do some kind of dependency injection (i.e., if you are testing one service A which needs another service B, then you have to tell A which B-feature it should take. But you need to do that anyway, in some form or fashion; as far as I can understand, you are trying to make the services (their branches) independent from each other, and I also assume from your question that you have one service per git repository (i.e., one service per branch) so you need to have them running per-branch.


Is it possible to template JIRA issues with pre-filled field contents?

I don't think you will be able to get far without any plugins. What you can take a look at is the Default Values for 'Create Issue' screen plugin. We were using it in the past, however gave up because defaults could be set only per issue type, and no other conditions. I was in contact with the supplier, though, and they confirmed that defaults per user and other extensions were on their roadmap. Makes sense to check if they are already available.


Getting a docker build ready for (Heroku) deployment?

For building docker image using docker-compose you can add build: field to the service you want to build and assign to it the path of the Dockerfile for example:

version: '2'
services:
  web:
    build: .
    ports:
     - "8080:80"
    volumes:
     - /project:/var/www/html

This example define a web service which:

Uses an image that’s built from the Dockerfile in the current directory.
Forwards the exposed port 80 on the container to port 8080 on the
host machine
Mounts the project directory on the host to /project inside the
container, allowing you to modify the code without having to rebuild
the image.

To build the image, simply issue the build command via docker-compose, as such: docker-compose build.


Configure Docker to use SSL for a private registry on Windows 10?

The official Docker documentation says:

  Docker recognizes certs stored under Trust Root Certification
  Authorities or Intermediate Certification Authorities.

That is, you can proceed as the following:

Start > "Manage Computer Certificates" (also available in the control
panel)
Right-click on "Trusted Root Certification Authoritites" >
"All tasks" > "Import"
Browse to the crt file and then keep pressing "Next" to complete the wizard
Restart Docker for Windows

In my case, the catch was that I imported the certificate via the context menu, and therefore it went to another folder where Docker could not access it. The certificate store behaves however very much like the normal Windows Explorer tree folder, so I had just to copy the certificate over to the supported category, and after Docker restart it worked.


For health monitoring, I would recommend the prometheus-operator. If you are looking for application logs, you should consider a logging stack such as elasticsearch-fluentd-kibana. I personally would recommend the kube-fluentd-operator. Additionally, if you would like to see the kubernetes events I find eventrouter quite useful which can also be wired into your logging infrastructure.


What tools should I deploy to support AWS for a Managed Services company?

Installing a box is probably not the best solution, mostly because there's no real need for it.

You should ask for an access to AWS console in customer account with proper rights fitting your responsibilities and maybe setup AWS config, Cloudwatch for the monitoring and alerting part, Cloudtrail and maybe Amazon Inspector for the audit part.

To ensure machines and AWS services themselves are properly configured you may rely on AWS Config/Amazon Inspector or tools like inspec (and here you may or may not need a bastion host on your customer VPC to check other machines, this mostly depends on the agreement you have with customer about direct links/VPN)


How to list containers that are using redis/ubuntu image in Docker

I think you want the ancestor filter :

From the Docker Docs on ps:

  ancestor - Filters containers which share a given image as an ancestor. Expressed as image-name[:<tag>], image id, or image@digest

$docker run -d --rm redis
c4cf36467d63c66f7d3d8271dd0f8e51ede4a627048eb5e294a2445f5b0d30ef
$ docker ps -f "ancestor=redis"
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
c4cf36467d63        redis               "docker-entrypoint.s…"   16 seconds ago      Up 15 seconds       6379/tcp            elated_yonath


Disabling HTTP Basic auth for requests from specific ips in k8s ingress

The thing I was looking for was external-auth in ingress-nginx. I created a simple service with nodejs which took over all the basic-auth logic. Then I used an external link to this service in k8s annotations for restricted resources.
annotation snippet:
  annotations:
    nginx.ingress.kubernetes.io/auth-url: http://service-name.default.svc.cluster.local:3000/auth


Bugzilla 4.2 to 5.0.4 'Can't locate parent.pm in @INC'

I needed to install a new perl module

yum install perl-parent

then I had to install make to install other dependencies:

cpan
o conf make '/usr/bin/make' #or path to your make
o conf commit


Add item(s) to yaml array only if defined (ansible)

Create the list in Jinja2 and convert it, e.g.
- hosts: localhost
  gather_facts: true
  tasks:
    - set_fact:
         ssh_listen_to: "{{ _ssh_listen_to|from_yaml }}"
      vars:
        _ssh_listen_to: |
          {% if ansible_default_ipv4.address is defined %}
          - {{ ansible_default_ipv4.address }}
          {% endif %}
          {% if ansible_default_ipv6.address is defined %}
          - {{ ansible_default_ipv6.address }}
          {% endif %}
    - debug:
        var: ssh_listen_to|type_debug
    - debug:
        var: ssh_listen_to

gives
TASK [debug] ********************************************************************
ok: [localhost] =>
  ssh_listen_to|type_debug: list

TASK [debug] ********************************************************************
ok: [localhost] =>
  ssh_listen_to:
  - 10.1.0.27

If you put the name of the variables into the list, e.g.
    vars_addr:
      - default_ipv4
      - default_ipv6

the task below gives the same result
    - set_fact:
         ssh_listen_to: "{{ vars_addr|
                            map('extract', ansible_facts, 'address')|
                            select('defined')|
                            list  }}"