ECS auto deploy with ECR I'm using github, jenkins, aws ECR, aws ECS.

I want to deploy automatically when github have new commit. When github have new commit, github sends a event webhook to jenkins, jenkins builds the images and pushes to ECR with tag 'latest'.

I wonder how can I make my ECS service restart task and redeploy images automatically when the ECR image is changed?

I don't think you can trigger re-deployment based on ECS image being updated. You can however do it as part of your Jenkins pipeline - after you push to ECR as a next step in the pipeline can run a script that will reload the task.

In fact in my pipelines I deploy the ECS Tasks through CloudFormation templates and the CloudFormation stack update is part of the pipeline. That way I update the ECS Task definition automatically every time I push a new image to non-prod ECR.

Hope that helps :)


Ansible hosts group reference does not work I'm trying for hours already to run a docker installation on a specific group of hosts.
This is my hosts.yml
all:
  hosts:
    01-dev:
      ansible_host: <IP1>
    02-dev:
      ansible_host: <IP2>
    03-dev:
      ansible_host: <IP3>

  children:
    docker:
      hosts:
        01-dev
        02-dev
    dev:
      hosts:
        01-dev
        02-dev
        03-dev

This is my site.yml

- name: Configure hosts
  hosts: dev
  tasks:
    - name: Update and upgrade apt packages
      become: true
      apt:
        upgrade: yes
        update_cache: yes
        cache_valid_time: 86400 #One day
    - name: Install needed network manager libs
      become: yes
      ansible.builtin.package:
        name:
          - network-manager
        state: present
    - name: "Configuring eth"
      become: yes
      community.general.nmcli:
        conn_name: "System ens18"
        ifname: ens18
        type: ethernet
        state: present
        autoconnect: yes
        ip4: "{{ansible_host}}/24"
        gw4: "192.168.3.1"

  hosts: docker
  become: true
  tasks:
    - name: Install aptitude using apt
      apt: name=aptitude state=latest update_cache=yes force_apt_get=yes

    - name: Install required system packages
      apt: name={{ item }} state=latest update_cache=yes
      loop: [ 'apt-transport-https', 'ca-certificates', 'curl', 'software-properties-common', 'python3-pip', 'virtualenv', 'python3-setuptools']

    - name: Add Docker GPG apt Key
      apt_key:
        url: https://download.docker.com/linux/ubuntu/gpg
        state: present

    - name: Add Docker Repository
      apt_repository:
        repo: deb https://download.docker.com/linux/ubuntu bionic stable
        state: present

    - name: Update apt and install docker-ce
      apt: update_cache=yes name=docker-ce state=latest

    - name: Install Docker Module for Python
      pip:
        name: docker

Then I run the command ansible-playbook -i hosts.yml site.yml -vvv --ask-become-pass and I get the error that there are no hosts for a group docker
What is wrong with my hosts file?

I think it should be:
children:
    docker:
      hosts:
        01-dev:
        02-dev:

(The colon)


Kubernetes api service unit file i was going through the kubernetes the hard way(kelsey), i see in the API server unit file with a cluster ip range as
 --service-cluster-ip-range=10.32.0.0/24 \
 is it a default ip range ?
my VPC CIDR is 172.31.0.0/16 this so should i need to provide this ip instead of default one ?

The --service-cluster-ip-range will define the range of IP address that Kubernetes will assign when you create a ClusterIP Service. It's different from your VPC CIDR which correspond to your nodes (EC2) IPs. You can let the default 10.32.0.0/24 as is or change it but make sure that it does not overlap with your VPC CIDR.


How to automatically deploy routers / industrial PC's I'm facing the problem, to setup Gateways and Industrial PC's (with SSH access) regularly. All have different default settings. Some have a default root password, some have a default user. Some have a initial fixed IP, some use DHCP.
Some are ARM architecture, some are MIPS. OS varies between Yocto, OpenWRT, Raspian, etc.

I'm looking for a way to somehow script the deployment and execute it automatically.

There are tools like Ansible, Puppet, Chef, etc. but I'm not sure which is best suited for my uscase described above or which isn't at all. In best case the tool has no requirements on the target device and works purely via SSH.

Regarding no requirements on the target device, of the tools you mention, only Ansible does not need an agent on the host. The minimal requirement to use Ansible modules is Python on the host you want to update. If you don't have Python on hosts you could even send raw commands to the hosts.

Wikipedia has a list comparing configuration management software, there you can find other agent-less tools.

Not listed on Wikipedia is Fabric, a simple Python library to execute remote shell commands. It is agent-less as well.


Jmeter simulating traffic and avoiding 429 I am using Jmeter to investigate the performance and capacity needs of a few web services. Jmeter sends traffic to the web-facing url (served by Nginx), with a rising rate, to see where the service fails. At the moment, this traffic is generated using a single machine, in the CI/CD pipeline.

Before I can really stress the resources, the web server is responding with HTTP 429

Is there a way to set data in the header or something to force each connection to be seen as new, instead of being banned by the server?

Edit : specified that the http server is nginx

Given that this is symptomatic of rate limiting in Nginx in this case, the solution is to configure the rate limiting feature of Nginx to allow this

A whitelist could  be created in the configuration to remove ratelimiting from the url generating the traffic.

To follow the Nginx documentation, this could be specified as whitelisting an IP.

The current server setup is :

limit_req_zone $binary_remote_addr zone=flood:10m rate=12r/s;
limit_req_zone $binary_remote_addr zone=bot:10m rate=200r/m;
limit_req_status 429;
limit_conn_zone $binary_remote_addr zone=connperip:10m;
limit_conn_status 429;

This sets up the rate limit on connections. A whitelist can be created as suggested above, by simulating a boolean condition with a key value map:

geo $limit {
    default 1;
    10.0.0.0/8 0;
    192.168.0.0/24 0;
}

map $limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

This removes the rate limit (sets it to 0) if the remote address falls into the whitelist:

limit_req_zone $limit_key zone=req_zone:10m rate=5r/s;

server {
    location / {
        limit_req zone=req_zone burst=10 nodelay;


Azure Pipeline PowerShell@2 Task can't run 'invoke-build' command as inline script (build PowerShell Module) I'm trying to build a PowerShell module in an Azure pipeline (dev.azure.com).
I've setup an initial pipeline and then building it up incrementally in small steps, because inexplicable errors are encountered far too easily on Azure.
I've added a 'Prepare' stage:
name: $(Build.DefinitionName)_$(Date:yyyyMMdd))

trigger:
- master

pool:
  vmImage: 'ubuntu-latest'

variables:
  major: 0
  minor: 0
  patch: $(Build.BuildID)
  buildVersion: $(major).$(minor).$(patch)

stages:
- stage: Prepare
  jobs:
    - job: Prepare
      steps:
      - powershell: .\bootstrap.ps1
        displayName: 'Install pre-requisites'

This is based on the original yaml that you get by default when you start a new Pipeline, so the part invoking the bootstrap file is what I got generated for free (This part works ok).
The bootstrap uses a dependencies file into which you can declare your dependencies and these are subsequently imported. One of those dependencies is InvokeBuild which contains the Invoke-Build command. So I would expect to be able to use the Invoke-Build command in subsequent stages.
The next part of the yaml pipeline is as follows:
- stage: Build
  jobs:
    - job: Build
      steps:
        - task: PowerShell@2
          inputs:
            targetType: 'inline'
            script: 'invoke-build build'

The invoke-build build, in itself is ok and valid and works on a local host.
The Build job fails with the following error:
/usr/bin/pwsh -NoLogo -NoProfile -NonInteractive -Command . '/home/vsts/work/_temp/edb3758b-8e16-448d-bea2-9ba18acb9693.ps1'
Invoke-Build: /home/vsts/work/1/s/do-build.ps1:3
Line |
   3 |  Invoke-Build build
     |  ~~~~~~~~~~~~
     | The term 'Invoke-Build' is not recognized as the name of a
     | cmdlet, function, script file, or operable program. Check the
     | spelling of the name, or if a path was included, verify that
     | the path is correct and try again.

I discovered there is another way to invoke the build with the PowerShell@2 task using the filePath input:
- stage: Build
  jobs:
    - job: Build
      steps:
        - task: PowerShell@2
          inputs:
            filePath: '$(System.DefaultWorkingDirectory)/do-build.ps1'

the do-build.ps1 script is defined as:
Set-Location .\Elizium.FakeBuddy
Invoke-Build build

(Elizium.FakeBuddy is the name of my PowerShell test module being built and that directory contains the InvokeBuild build script)
but this fails with the exact same error.
So why is the invoke-build command not available in the PowerShell session at the build stage, even though the Prepare stage has already imported the module?
The only thing I can think of is that different stages somehow don't share the same PowerShell session, but I don't know if this is correct, this seems unlikely, it doesn't make sense that different stages don't share the same session.
EDIT: I tried an alternative version where the Build job is declared inside the same stage as Prepare, but this makes no difference, still a problem with Invoke-Build command.

I'm not familiar with Invoke-Build, but appearantly it's a part of the InvokeBuild PowerShell module? In that case, you'll have to install the module as part of the script where you're using it. Your YAML should be something like this:
- stage: Build
  jobs:
    - job: Build
      steps:
        - task: PowerShell@2
          inputs:
            targetType: 'inline'
            script: |
              Install-Module InvokeBuild
              Invoke-Build build

As @Michael Erpenbeck said "the hosted agent starts off as a clean slate". That is to say that it starts off as a clean slate for each job in your pipeline. I'm not sure what bootstrap.ps1 is supposed to do so I can't really comment on whether that script and your Invoke-Build should be run as steps in the same job. But the main point to remember is that any requirements beyond what the standard Azure Pipelines agents offer should be taken care off within each job.


ansible-pull ignore group_vars vault How do I ignore the group_vars vault file when running ansible-pull?

My repository (among other stuff) does machine init, joining the domain and software updates. I would like the software part to be handled by ansible-pull. No passwords are required for this, and no vault is necessary.

Unfortunately, initial machine setup after a fresh install does require some passwords which are set in group_vars/all.yml and is encrypted by vault. Whenever I run the ansible-pull command I run into vault decryption issues as there is no password provided.

Any advice on how to overcome this?

Eventually I just got rid of the group_vars all together.
I specified a new role that includes several other roles with 'include_role:' and added the vars directly to those roles with inline-vault variables:

- name: include ipaclient
  include_role:
    name: ipaclient
  vars:
    my_user: user
    my_password: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          123456123456123456123456123456132456...


How do I deploy an applications to Kubernetes with Minikube? I would like to do something like this, but all Kubernetes quickstart demos are just for deploying a simple applications and not multiple.

How would I create a yaml file that can deploy multiple applications like this with Minikube?

Deploy tomcat to minikube
Deploy sample.war to tomcat (https://tomcat.apache.org/tomcat-8.0-doc/appdev/sample/ )
Bind tomcat service to hostport 8090
Deploy nginx/apache to minikube
Bind nginx/apache to hostport 8080

Welcome to the wonderful world of container orchestrators. It is considered bad practice to install many apps into a single container. The new way of working is not to install an application server that runs many WAR files. The new way of deploying is to have each app be a self-contained container where your build tool (eg maven) packaged the servlet container and your app together into a single file. Then each container can be deployed to Kubernetes and independently scaled up and restarted. They can also have memory leaks and crash without effecting each other.

One good example of that is springboot where in your pom.xml you can tell it to build an executable JAR. This will be large as it will include Tomcat into it. When you run the executable file it will launch java and Tomcat and bind to a port and run your app. You don't have to use springboot you can simply add the Tomcat or Jetty plugin to your maven project and have the container just launch "mvn jetty:run" or "mvn tomcat7:run".

I recommend you try minishift which is like minikube but the openshift distro of kubernetes that has more devops features. If you want to deploy Java Servlet apps you just use its built in catalog, select "Open JDK" supply it with your git repo, and it will checkout your code, build the app with maven, create a container image, and deploy the it, with a route and URL you can access it. Yet you can create things from scratch the catalog is just creating all the necessary YAML. Here is the sample code that you would use as your maven project that can be built and run by the "Open JDK" catalog. The  pom.xml shows that when the code is built with mvn -P openshift package it puts the war file into a deployments folder and jboss will run it when the container is started. If you don't like jboss then you can add a .s2i/bin/run script that starts your compiled application another way (e.g. "mvn jetty:run" or "mvn tomcat 7:run")

Helm is a package manager for Kubernetes it works with openshift extensions also. Helm tracks what your have installed and lets you rollback. The official chart repos have ready made charts to install databases and redis etc. I made a generic chart that runs any container on openshift kubernetes and we use it to install all our apps whether mode.js or php or whatever. It uses the same YAML as the built in templates use.

When you want to install many charts then you can use Helmfile. Your Helmfile has all the yaml to install all your helm charts. The best feature is that it only modifies what changed. If you modify one setting in a Helmfile that configures many apps it will only update the one app. And let you see the prior versions of the k8s yaml of the apps store in k8s and lets you easily rollback to the last working state.

I am making open source the stuff we run a business with as “OCD” where you change the config in git and a webook will run Helmfile to update your Kubernetes env. Here is the minishift demo how-to.


What 'ChatOps' books and resources are available? We have defined what ChatOps is in the form of the following question:

What are ChatOps approach use cases of production infrastructure management?:

  Practically it means something very different to each team using it.  So much so that Atlassian have put together what could be considered to be a Chat maturity model.

  Sputnik: Trying chat out to see how it works.
  Mercury: Starting to move to chat.
  Gemini: Chat as the primary source of communication, experimenting with bots.
  Apollo: Chat as the nexus of communication and work, including bots.
  Elon Musk: Chat is the primary centre of mission critical work.

What other books and resources are available that describe the people, process and tools used to implement ChatOps within an organisation.

One of the people active in ChatOps community is Jason Hand from VictorOps, who wrote a book published by O'Reilly called Managing Operations in Group Chat. This book is available for free as part of their content marketing campaign. The previous ChatOps for Dummies is no longer available and is replaced by the above book.

You should definitely take a look at Slack Apps, especially the Developer Tools. There is article by SlackStorm on how to integrate Ansible and Slack.

You might also monitor the subreddit on chatops. There is a long sidebar of resources including the video from GitHub ChatOps presentation and many more.

I would also recommend to look at Cog from operable.io and the Cog Book.


Safari test automation using Robot Framework via Jenkins I spent about one week trying to make my Robot Framework tests work for Safari browser in MacOS, when launched by Jenkins via ssh.

The main issue was that Robot couldn't open a browser when executed in ssh session, reporting "No browser is open".

MacOS 10.12.6 Sierra (issue was there also with 10.14 Mojave)
Safari 12.1.2 (issue was there also with Safari 10)
Robot Framework 3.1.2 (Python 3.6.8 / Python 2.7.16)

My current workaround is:

Application "robot_test" created (in Automator based on shell script type) which is to launch a shell script and save the exit code:

/tmp/execute_test.sh > /tmp/execute_test.log 2>&1
echo "export EXITCODE=$?" > /tmp/execute_test.result

On the Jenkins side, in the shell command section, I am creating an shell script with the contents I need, execute it and wait for result file to appear:

export CURRENT_FOLDER=`pwd`
echo "#!/bin/bash
~/.bash_profile
cd $CURRENT_FOLDER
python3 -m robot -parameters robot_script.robot
" > /tmp/execute_test.sh
chmod +x /tmp/execute_test.sh
rm -f /tmp/execute_test.result
MAX_WAIT_TIME=1200
WAIT_TIME=0
open -a robot_test > /tmp/robot_test_app.log 2>&1
while [ ! -f /tmp/execute_test.result ] && [ $WAIT_TIME -le $MAX_WAIT_TIME ]; do
  WAIT_TIME=$((WAIT_TIME+10)); sleep 10
done
cat /tmp/execute_test.log

EXITCODE=1
if [ -f /tmp/execute_test.result ]; then
  chmod +x /tmp/execute_test.result
  source /tmp/execute_test.result
fi
exit $EXITCODE

Am I the only one having problems with running robot test from ssh sessions in MacOS?
If yes, could you please share you steps to configure the proper setup?
If no, then this post might be helpful for someone to have working configuration at least, please share your solutions/workarounds if they are better.

Do you run selenium as a separate process?
I had the same issue if you are not running selenium in the background.

(edit)
Try java -jar selenium-XX.XX.jar in terminal.

After that run pabot or robot command to run the tests.
You can crate app through the Automator and use the same approach you describe to call it from the CI. That is what I end up using.


Is the root user in a Docker image/container the same as the root user of the machine? Is the root user in a Docker image/container the same as the root user of the machine? I am curious about the security implications of using the root user in the Docker image.

TMK, the container is run by a non-root user (often the user is called "docker") and that user launched the docker-dameon. And the docker daemon launches the container process.

No the root in container is a root-user of container. Remember containers runs isolated.
DOcker uses cgroups and libvirt of kernel linux.


Push specific changes (defect fix) and not feature changes I am new to DevOps. I am using Jenkins and GitHub for salesforce deployment.

Setup

We have a develop branch. Feature branches are created out of it. When merged to develop, the deployment to the first Salesforce sandbox happens. After end of every sprint the develop branch is merged with SIT branch pushing changes to SIT Sandbox.

Problem Statement

The QA happens in the 1st sandbox for sprint 2. QA also takes place in SIT Sandbox for sprint n-1 features.

If an issue is found in the SIT sandbox as part of sprint n-1 testing, the bug is fixed in the develop Sandbox

a defect feature branch is created from develop.
A fix is added to it.
The branch is merged to develop, fix deployed to 1st Sandbox and tested.

If it passes QA, the defect feature branch needs to be  merged with the SIT branch to deploy the fix to the SIT sandbox and testing resumes.

Issue

Only the fix needs to be pushed to SIT before the sprint is over and not user story code from sprint 2. But if the fix is made to an apex class or object file, everything is deployed.

How would one separate the user story code from sprint 2 and defect fix code for sprint n-1 testing when merging to SIT branch?

This sounds like a problem for git cherry-pick. If you can separate the user story code from the fix code, by committing them separately, you can cherry pick the relevant commit to merge back into the develop branch.

See https://stackoverflow.com/questions/9339429/what-does-cherry-picking-a-commit-with-git-mean


Is it possible to mount an s3 bucket as a point in a docker container? I have a Java EE packaged as war file stored in an AWS s3 bucket. I will like to mount the folder containing the .war file as a point in my docker container. I have managed to do this on my local machine. Below is an example of a JBoss wildfly deployments. How can I use s3 for this ?

docker container run -d —name Application -p 8080:8080 -v `pwd` /Application.war: /opt/jboss/wildfly/standalone/deployments/Application.war jboss/wildlfly

No you can't.

S3 is an object storage, accessed over HTTP or REST for example. Just as you can't mount an HTTP address as a directory you can't mount a S3 bucket as a directory.

Having said that there are some workarounds that expose S3 as a filesystem - e.g. 's3fs' project. How reliable and stable they are I don't know.


Enabling CSRF Protection prevents editing/adding parameters to jobs - intentional or bug? Recently Jenkins has been putting out a number of security warnings related to CSRF Protection. We tried enabling it on our version of Jenkins (ver. 2.89.2) only to find that with it enabled you can no longer add or edit parameters on either freestyle or pipeline jobs via the GUI.

I did fairly extensive testing to narrow it down as the culprit, but I still don't understand why the option exists and is being recommended if it cripples Jenkins jobs.

Is this a feature or a bug? If it is a feature, why? What's to gain?

I believe this may be a result of running Jenkins behind a proxy, which can cause legitimate requests to perhaps appear to Jenkins as cross-site requests.  From the official wiki:

  If you are using nginx as a reverse proxy in front of Jenkins, you need an extra system property on Jenkins "-Dhudson.security.csrf.requestfield=Jenkins-Crumb". See JENKINS-23793 for more details


Deploying a statefulSet with static volume provisioning but controller insists to use dynamic I am trying to deploy a statefulSet that will use static volume provisioning (claim existing PVs) based on their label. However, it seems that the persistentvolume-controller is trying to provision storage dynamically, as when I kubectl desribe pvc db-data-db-N the Events log states that:

Events:
  Type       Reason              Age               From                         Message
  ----       ------              ----              ----                         -------
  Warning    ProvisioningFailed  9s (x3 over 21s)  persistentvolume-controller  Failed to provision volume with StorageClass "db-data-storage": claim.Spec.Selector is not supported for dynamic provisioning on AWS

I have pre-provisioned PVs with this format (I am using Helm):

kind: PersistentVolume
apiVersion: v1
metadata:
  name: db-data-{{ $volIndex }}
  labels:
    restoredFromBackup: "true"
spec:
  capacity:
    storage: 30Gi
  accessModes:
  - ReadWriteOnce
  awsElasticBlockStore:
    volumeID: {{ $volId }}
    fsType: ext4

Here is my PVC template:

  volumeClaimTemplates:
  - metadata:
      name: db-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 30Gi
      selector:
        matchLabels:
          restoredFromBackup: "true"

Did you try by specifying a storageClassName since Kubernetes will be using default storage class when it's not specified?
See Dynamic Provisioning of the blog post and Dynamic from Kubernetes documentation?
Or try with by removing the default storageclass in the cluster to explicitly use given PV and PVC configuration.


How do I do a dry run with docker-compose? I want to know what docker-compose is going to do before I do it.

Is there a tool or flag which I can use to see what docker-compose would do without actually stopping containers and starting new ones?

Welcome to DevOps SE!

A dry run for docker-compose seems to be an open feature request.


Why is environment variable mangled in docker compose environment file Context: docker-compose to start several containers, including Gunicorn that calls a Flask app. I'm using an environment file web/env.gunicorn to store my Gunicorn startup configuration. This file contains

GUNICORN_CMD_ARGS="--bind=127.0.0.1:8001 --workers=3"

The problem is that GUNICORN_CMD_ARGS is not processed correctly somewhere in the pipeline. The error that I get when running docker logs gunicorn is

Error: '8001 --workers=3' is not a valid port number.

The question is, where in my setup are my assumptions wrong, thereby causing the environment variable to be mangled? The environment variable is accepted when run manually in a terminal. The docker compose file looks as follows

version: "3"
services:
#  nginx:
#    image: nginx:latest
#    ports:
#      - "80:80"
#    volumes:
#      - ./nginx:/etc/nginx/conf.d
#    depends_on:
#      - web

  web:
    build: ./web
    container_name: gunicorn
    ports:
      - "8001:8001"
    environment:
      - APP_CONFIG_FILE=../config/development.py
    env_file:
      - 'web/env.gunicorn'
    networks:
      - backend
    command: gunicorn thymedata:app
    depends_on:
      - influxdb
      - grafana

  influxdb:
    image: influxdb:latest
    container_name: influxdb
    ports:
      - "8086:8086"
    env_file:
      - 'influxdb/env.influxdb'
      - 'influxdb/secrets.influxdb'
    networks:
      - backend
    volumes:
      - influxdb-data:/var/lib/influxdb

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    env_file:
      - 'grafana/env.grafana'
      - 'grafana/secrets.grafana'
    networks:
      - backend
    volumes:
      - grafana-data:/var/lib/grafana
    depends_on:
      - influxdb

networks:
  backend:

volumes:
  influxdb-data:
  grafana-data:

I had a similar problem and this worked for me without it feeling like a hack...

docker-compose.yml:

version: '3'
services:
   web:
      build .
      environment:
      - GUNICORN_CMD_ARGS=--workers=0 --bind=0.0.0.0:8000 --timeout=10

Note: add env GUNICORN_CMD_ARGS without quotes

Dockerfile:

FROM python:3.6-slim
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
ENV GUNICORN_CMD_ARGS="--bind=0.0.0.0:8000 --workers=3"
CMD gunicorn app:app

Note: run CMD gunicorn app:app without passing options via array or quotes


CI/CD ARM Templates - Should the cloud infrastructure and resources be checked on each deployment? Given a company adopts infrastructure as code deployment model using ARM templates.
Is it a good practice to attempt to re-deploy the ARM templates alongside the application itself ?
If yes what deployment mode (incremental/substitution) should be used and why?
Thank you!

if you are doing ARM then follow the replace ideology if you can manage to have things stateless but if not then maybe go via the Terraform route than ARM IMHO


Is there a way to disable a Jenkins plugin for a single job? I use the Build timeout plugin to alert when jobs are stuck. I have one job that triggers this alert because it contains a step with a long execution time. I would like to disable the build timeout plugin but only for that job, is there a way to do so? I'm using Jenkins v2.22.

We don't use the built-in option for the job not to terminate on timeout, we use sensu plugins to monitor the state of the likelyStuck variable.

Sadly I just switched jobs and I don't have access to a Jenkins instance (least not yet) so I cannot try it out for you.

That said some ideas quickly jump in my mind that could get you there.

I've had some success with the conditional build step plugin though I don't know if it would work for build timeouts.

If not directly perhaps as a means to change some values through the rest API ? Maybe using job parameters ? You could also split the job in two and call the appropriate one (with or without timeout) using a conditional build step (mentioned above)...

If you are int a pipeline you could use the timeout in a jenkins file.
https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#code-timeout-code-enforce-time-limit.

let me know if any of this is helping you.


docker-compose multiple services in a loop Trying to optimize definition of multiple services with docker-compose.yml

Here is the original, "dumb" variant of the docker-compose.yml:

version: '3'
services:
  s1:
    build: .
    ports:
    - "5001:9000"
    volumes:
    - ../www1:/var/www
  s2:
    build: .
    ports:
    - "5002:9000"
    volumes:
    - ../www2:/var/www
  s3:
    build: .
    ports:
    - "5003:9000"
    volumes:
    - ../www3:/var/www

Is there some sort of an iterator to compact this to just one block like the following?

version: '3'
services:
  for i in 1,2,3:
    s$i:
      build: .
      ports:
      - "500$i:9000"
      volumes:
      - ../www$i:/var/www

Not in pure Docker Compose.  If you have a plain-text templating engine you like (Mustache, Jinja, m4, ...) you can ask it to do this for you.

You tagged this as shell-script, and Compose can take the YAML configuration on stdin, so in principle one option is to write a shell script, and then pipe that into docker-compose:

#!/bin/sh

buildComposeYaml() {
  cat <<HEADER
version: '3'
services:
HEADER
  for i in $(seq 3); do
    cat <<BLOCK
  s$i:
    build: ../www$i
    ports:
      - "500$i:9000"
BLOCK
  done
}

buildComposeYaml | docker-compose -f- "$@"

(Note that YAML is indentation-sensitive, and the script is mixing indentation for the script itself, the YAML embedded in the script, and the end-of-heredoc markers; so this will work for a simple tool but it wouldn't be my long-term choice.)


Software Security Testing in a DevSecOps Pipeline This is a somewhat general question by design, intended for discussion of process. At my current (and all previous) companies we had issues with releasing insecure software into production. This cut across the divide from mobile, web, API's, internal, external, critical and non-critical applications and systems. If we built it, it had/has security issues... just like your company. In addition, we lack support stack (qualified application security engineers who "knew code" and not just glorified pen testers who didn't know JavaScript from Java) so we could not scale services as needed. Hence automated software security scanning in the SDLC and now in the DevSecOps CI/CD pipelines. We face the issues of:

Service Level Agreements - our dev teams want/need results in minimal time, we all know that's not happening with either DAST or SAST tools without heavy configuration.
Allowing teams to choose their own language and not even having static code support... leaving us with DAST if applicable or, ugh, pen tests, which in my view are essentially useless.

We need to shift software security "left" - from point of inception, not wait until code is in production and hope we detect the vulnerabilities - I am sure someone will find them, most likely not the pen test team we are paying huge money for, however.

Automation of static and dynamic tools, properly configured, driven off a threat model seem to be our only options to get ahead of the game. We all know "developer education" is a lost cause.

How is your company/team solving this, assuming they even are or recognize it as a problem to address?

I agree that relying on "developer education" is quite futile, at least when it's the sole course of action. Combine this, however, with automation and you can achieve far greater impact. Both sides, DAST and SAST can be covered with:

Unit test authentication: Make sure that you have unit tests that check registration, login, password reset and that it is integrated with your development process (continuous integration). Implement processes that automatically block changes to your code when they fail.
Testing against known vulnerabilities: These are automated DAST tests that test your application from outside. Programs that handle this task include BDD and mittn which is inspired by GAUNTLT.

Integrate everything properly with a CI server (Jenkins, Gitlab, Travis) and stop having to rely on your programmers' "best effort security"

Note: my opinion of proper CI integration, from a language/platform agnostic view, covers the following

Tests/examples:
 - unit tests that cover at minimum 80%, better 90%
 - integration tests that ensure the modules work with one another
 - example programs that show how a user should use the API

Build automation:
 - Automatically build every pushed commit
 - Build library, test and example code
 - Build for each platform/configuration
 - Run the tests

Merge/pull requests:
 - Block merges into master branch if any thing fails
 - Require code review of at least one other colleague

Code analysis:
 - Run nightly static code analysis (style, anti-conventions, dangerous constructs)
 - Run nightly dynamic code analysis (memory leaks, race conditions, known security flaws)

Publish results:
 - Publish graphs/trends of test/analysis history
 - Talk about changes/targets in weekly meetings
 - Act on problem areas with sprints/work packages


Does Docker allow containers to be OS agnostic? We currently use a Windows based server to host 2 VMs. One VM uses Windows with a Windows app and the other VM uses Linux with a Linux app.

Is the below scenario possible?

Bare server with Windows 2016 (no VMs). Install Docker engine. Install Windows app container. Install Linux app container.

Does the Docker engine abstract away the OS such that this configuration will run both apps? Meaning that the Docker engine works as an "interpreter" akin to how Java code can run on various OS's?

Does the Docker engine abstract away the OS such that this configuration will run both apps?

No, it does not. Docker uses containerisation as a core technology, which relies on the concept of sharing a kernel between containers. If one Docker image relies on a Windows kernel and another relies on a Linux kernel, you cannot run those two images on the same OS.

When you install Linux Docker on Windows, you're actually setting up a Linux VM in Hyper-V, the LinuxKit details are here. You can open the Hyper-V console and see a VM called "MobyLinuxVM". There's a lot of work done to abstract this away from you e.g. the docker binary can connect to the Linux VM and run the same commands you're used to, networking between the host and VM tries to be seamless, volume mounting, etc. Ultimately it's not Docker that lets you run a Linux Docker image on Windows, it's just plain old virtualisation.


Google Cloud Registry and multiple projects Is it possible to pull images from the same GCR from multiple GCP projects without making the registry public?

I want to do this so I do not have to upload multiple times the same image to multiple registries so it can be used on different projects.

Yes, it's possible. Fundamentally GCR is built on top of Cloud Storage, with roughly the same basic access control:

public, i.e completely accessible
private, with quite flexible access control from pretty much anywhere, even from outside the GCP domain - being in a certain GCP project is rather irrelevant.

From Granting users and other projects access to a registry:

  To give specific users or container clusters running on other projects
  permissions to pull images from a registry, you need to grant read
  permission on the underlying Cloud Storage bucket.

  ...

  Select the Permissions tab.
  Click Add members.
  From the menu that appears, fill the Members field with the email addresses of users needing read permission, separated by commas.
  This email address can be one of the following:

  a Google account (for example, someone@example.com)
  a Cloud IAM service account
  the Compute Engine default service account of another project. This account is used by the Google Kubernetes Engine to pull
  container images clusters by default. It is in the form
  [PROJECT_NUMBER]-compute@developer.gserviceaccount.com, where
  [PROJECT-NUMBER] is the GCP project number of the project that
  is running the Google Kubernetes Engine cluster.

There are some differences from Cloud Storage, most notable ones being:

access control applies to the bucket level only, object level access is ignored
GCR can only have a single bucket per GCP project


Need a folder, always updated with the latest code from Git I wonder if anyone knows of a tool or method that I can use to accomplish my goal of having a folder that always contains a copy of the latest code from my Git repository.

I need it to work generically with Git, as it may be hosted on VisualStudio.com, Bitbucket, GitHub or any other Git provider.

Background: I have a requirement to keep all the latest code in a big data store in Azure. It will be hundreds of repositories, frequently adding more. I find it more scalable to download the code from a folder rather than integrating directly with Git with that many repositories. So I am looking for some existing method or tool to go in-between and place a copy of the latest code from my Git repository in a folder.

Use a Git post-receive hook to issue a git pull in the directory you want to keep updated. You might want to mount the directory you want to keep updated locally to the Git server, or execute that command remotely with ssh into Git Bash on Windows, or Powershell. Alternatively have the hook call a webhook and have the webhook execute the git pull. The webhook method will be easiest with BitBucket, I don't know about the others.


How to create a second IP just for dockers Problem: my server is already using port 80 and I would like launch another service that uses port 80 on another address (I don't want to remember ports or force my wife to use non-default ports).
I've created a secondary IP address for all of my dockers (the dockers themselves will only map their ports to one address) but my server grabs port 80 for the default service on both addresses.
Is there a docker way to create a second IP address and avoid this problem?
Thanks

If you pass the listen address as the very first component of -p, Docker will only listen on that address:
$ docker run -p 127.0.1.2:8080:80 -d nginx`
$ ss -ltp | grep 127.0.1.2
LISTEN  0       4096         127.0.1.2:http-alt          0.0.0.0:*


Kibana slow performance optimization I have a Kibana page which takes about 7-10 seconds to load.
Benchmarking same page shows ~1s to complete the request
$ ab -n 10 "http://kibana/app/discover#/view/15a67850-6921-11ea-8308-058e42e28132"

and the exact same query to elastic takes about 1s to complete as well.
$ ab -n 20 -p same-query.json -T application/json "http://kibana:9200/logstash*/_search"

It's just 2 simple match filters within a request to logstash* index.
Taking into account benchmarking above I don't think the the issue related to Elasticsearch/Logstash but rather to Kibana itself. So my questions are:

Is the a way to tune/optimize performance for Kibana (page loading time)?
In case I move Kibana UI to separate instance will that give any benefits to performance? (currently it's ELK stack on the one instance 8 vcpus, 16 GiB memory)
How can I additionally narrow down the exact reason of this slow performance?

So basically I've ended up turning these flags off (/app/management/kibana/settings)
filterEditor:suggestValues
discover:searchOnPageLoad
doc_table:highlight
visualize:enableLabs
telemetry:enabled

Other ideas I had in mind:

adding nginx as a proxy caching all the static files (js for plugins / images)
warmup script (periodically makes requests to predefined hot pages for Kibana to internally cache these pages) if that would work
migrate to hosted cloud solution which might be optimized better for the loading time


Is Elastic Beanstalk suitable for enterprise-grade CD? I'm working with a project that's using Jenkins to build and deploy microservices to Elastic Beanstalk. We deploy an integration branch to a test environment, release branches to a staging environment, and then a final master build to production. I have a couple of concerns with doing it this way: first, it means we end up with a matrix of one build per project per environment, duplicating efforts; and two, it means we aren't deploying the same build artifacts to production that were validated in staging.

I'm inclined to abandon Beanstalk and move to plain ASGs using something like Chef for deployments. That would leave us with one build per project, producing a build artifact, and we could deploy the same artifact to production that was approved in staging. Transitioning has a not-insignificant up-front cost, however. Is there some way to use Beanstalk better that would allow for more reliable, easier-to-manage CI/CD?

Note: Promoting the same build artifact is exactly what I want to do, but from the docs I don't see any clear way to do that; it explains how to deploy to EB from your app source, but not how to promote an existing version to another environment, unless I managed to scroll right past it. If it is available in EB itself, there may be a limitation in the Jenkins EB deployment plugin that prevents it from being done in Jenkins specifically, but I haven't seen a way to do it at all.

IMO opinion your issue isn't with Elastic Beanstalk in that scenario, it's with Jenkins, or at least the way you're using it. You should really concentrate on building "a thing" only once, regardless of what that thing is.

Full Disclosure: I work for ThoughtWorks and am incredibly biased to GoCD. I'll try to spell out what I mean in as neutral was as I can. I will use our tool's docs are examples, but hopefully people can extrapolate to their systems.

Somewhere early in your pipeline you're building "artifacts". This could be binaries representing all or part of your application, or they could be output from any number of tools such as testing tools. These artifacts should be stored by the system and never built again. The system should then fetch the artifact from the proper revision when needed.

For example...

I build a .jar file and run some unit tests on it, basic C/I stuff. If it passes, that .jar file and the output of the tests gets uploaded to that specific pipeline job.
The next pipeline could be your deployment to a more complex testing environment. It should fetch the exact jar from the exact job that built it. It then executes Elastic Beanstalk to deploy that jar to the correct environment.
The next pipeline is your staging deployment. It goes all the way back to the first pipeline and fetches the exact jar from the exact job that built it. In then executus Elastic Beanstalk to deploy that jar to the correct environment.

These are each separate pipelines because that allows you to run more in parallel or on demand without blocking.

You could use Elastic Beanstalk, Chef, Puppet, Ansible, uDeploy or any number of other tools to do the actual deployments. That's not where your issue is coming from. Continuous Integration servers weren't built originally to do this. Of course there are lots of plugins you can use to get to the same place if that's your preference.

Continuous Delivery servers like GoCD, Chef Automate and ConcourseCI were built specifically to solve things like this.


How to start a service in fedora container without using systemd? I want to start a service in my fedora docker container.
But since systemd is not working in the fedora container. I am unable to start the service. I'm getting following error.

  Failed to connect to bus: No such file or directory

In Ubuntu container, I am able to start any service using /etc/init.d/.
I want to know any other way to do the same for my fedora container.

Running systemd inside the container should not be required as docker run eventually does the same thing. Make changes in your run scripts to make them independant from systemd.
If you still insist on using systemd and do not care about how docker works, there is a way to let systemd work inside the container. Follow this link:

https://developers.redhat.com/blog/2014/05/05/running-systemd-within-docker-container/


Where is it said I can safely the same local volume to multiple docker containers? According to that StackOverflow answer:

  Yes you can add same location as a volume to many docker containers.

But I read the Docker Volume documention and I can't find where it is said a local volume can safely be shared between several containers on the same host. Could someone point me to an official statement regarding that?

By a "local volume" I assume you mean a block device directly attached to the host, such as a "normal" internal disk.

The standard way to run multiple Docker, containers now is Kubernetes, since the demise of Docker Swarm. My reference here is the Kubernetes documentation for Persistent Volumes specifically the table on Access Modes, and the column for ReadWriteMany. A local volume would be a HostPath which is not supported for this use case. However if you were using iSCSI it would support ReadOnlyMany, and if you used NFS you could get ReadWriteMany.


JenkinsFile to get git branch name I want to get git current checkout BRANCH NAME in my Jenkins file here is the code snippet...
Here I am trying to push a file to my current branch
I have tried many things could not find it...

stage('Push yaml file to bitbucket'){
  steps{
    withCredentials([usernamePassword(credentialsId: '8e2ca0a6-2dc5-4f89-b76a-03076d6b0843', passwordVariable: 'GIT_PASSWORD', usernameVariable: 'GIT_USERNAME')]) {
      sh '''
        echo '#!/bin/sh' > /home/jenkins/git_askpass.sh
        echo "exec echo \"${GIT_PASSWORD}\"" > /home/jenkins/git_askpass.sh
        chmod 775 /home/jenkins/git_askpass.sh
        echo "user: ${GIT_USERNAME}"
        GIT_ASKPASS=/home/jenkins/git_askpass.sh
        export GIT_ASKPASS
        cat /home/jenkins/git_askpass.sh
        pwd
        git status
        git checkout feature/OSCCX-44(here I want branch name )
        git config --global user.email "xyz.com"
        git config --global user.name "xyz"
        git add yaml_dev/04-idm-frontend-depl.yaml
        git commit -m "jenkins commit"
        git push https://${GIT_USERNAME}@bitbucket/repository '''
    }
  }
}

If you check the Git plugin documentation, you can see that there is a GIT_BRANCH environment variable that you can use in your pipeline.

GIT_BRANCH - Name of the remote repository (defaults to origin),
             followed by name of the branch currently being used,
             e.g. "origin/master" or "origin/foo"

So, in your pipeline:

stage('Push to Bitbucket') {
    steps {
        withCredentials([usernamePassword(credentialsId: '8e2ca0a6-2dc5-4f89-b76a-03076d6b0843',
                                          passwordVariable: 'GIT_PASSWORD',
                                          usernameVariable: 'GIT_USERNAME')]) {
            sh '''
            # Content omitted
            git checkout ${GIT_BRANCH}
            # Content omitted
            '''
        }
    }
}


container on same network with host Our application is a combination of 4 different applications. The graphics part is running on a host and other 3 applications are running on 3 different VMs. Which uses bridge networking.

eg. Graphics app1 - 192.168.2.201 (Base Machine/HOST)
    Application 2 - 192.168.2.202 (VM1)
    Application 3 - 192.168.2.203 (VM2)
    Application 4 - 192.168.2.204 (VM3)

Which is running fine.

But, to get advantage of containers, we want to shift our VM applications into docker container. But in docker, when we are using Bridge Networking, it doesn't take IPs in HOST network, obviously because, Bridge network ID is not same as host. And application fails to run.

How can we achieve the Bridge Networking with same network ID (say 192.168.2.0)? We cannot use Host networking.

Note: our application specifically wants IP in 192.168.2.0 network, otherwise it fails.

I could have mentioned this in comment first but I need 50 reputation to comment and I just joined this yesterday,

So, may I know what you are trying to achieve? If I interpret correctly, you want to move your VMs to Docker and then make those docker interact with each other as well as with graphics which is running on host? So consider it this way, you have 4 IP addresses, how would you make the communicate if it is simple LAN? Similarly you do it here. Allow hosts from that IP to work here.
You can customize docker0 bridge to have gateway and CIDRs of your choice by modifying daemon.json

Customize the Docker0 bridge

You can create your user defined networks too.

May be this will help you too?
Docker Networking User Guide

You can even write your own network plugin.


How to use n3dr with nexus 3 servers with self-signed certificates? Is n3dr compatible with nexus 3 servers that use a self signed certificates?
If so, how to access such repositories?

./n3dr-linux repositories -u xxxx -p xxxx-n https://xxxx -a
WARN[0000] ~/.n3dr.yaml does not exist or yaml is invalid
FATA[0000] Get https://xxxx/service/rest/v1/repositories: x509: certificate signed by unknown authority

[UPDATE]

Related issue on gihub: https://github.com/030/n3dr/issues/107

@titou10 created a pull request and solved it in version 3.3.4-rc1.

This is to inform that the issue has been solved.

https://github.com/030/n3dr

https://github.com/030/n3dr/tree/3.3.4-rc1


How many builds does jenkins need to run before it has estimated times? We just updated our Jenkins to v2.207.1 and our build estimation times on pipeline jobs have stopped showing up. Rather than a blue bar that when hovered over shows an estimate, we are now seeing the blue-and-white striped barber pole and an estimation of N/A.

I believe this behavior might be only on pipeline jobs - we have so few freestyle jobs that I haven't seen them run yet.

What logic does Jenkins use to calculate those estimations? How many builds will we need before those times fill back in?

I checked out the Jenkins source code, and I believe Jenkins uses the last 3 successful or unstable builds for its estimation. If it out of the last 6 builds it can't find 3 successful or unstable builds, it uses 1 or more of the last completed (not aborted) builds. It then takes the total duration time of the "candidates" and simply divides it by the number of candidates (i.e. mean of the durations). Here is the code I based this off of that can be found in the Job.java file in the Jenkins repo:

    /**
     * Returns candidate build for calculating the estimated duration of the current run.
     *
     * Returns the 3 last successful (stable or unstable) builds, if there are any.
     * Failing to find 3 of those, it will return up to 3 last unsuccessful builds.
     *
     * In any case it will not go more than 6 builds into the past to avoid costly build loading.
     */
    @SuppressWarnings("unchecked")
    protected List<RunT> getEstimatedDurationCandidates() {
        List<RunT> candidates = new ArrayList<RunT>(3);
        RunT lastSuccessful = getLastSuccessfulBuild();
        int lastSuccessfulNumber = -1;
        if (lastSuccessful != null) {
            candidates.add(lastSuccessful);
            lastSuccessfulNumber = lastSuccessful.getNumber();
        }

        int i = 0;
        RunT r = getLastBuild();
        List<RunT> fallbackCandidates = new ArrayList<RunT>(3);
        while (r != null && candidates.size() < 3 && i < 6) {
            if (!r.isBuilding() && r.getResult() != null && r.getNumber() != lastSuccessfulNumber) {
                Result result = r.getResult();
                if (result.isBetterOrEqualTo(Result.UNSTABLE)) {
                    candidates.add(r);
                } else if (result.isCompleteBuild()) {
                    fallbackCandidates.add(r);
                }
            }
            i++;
            r = r.getPreviousBuild();
        }

        while (candidates.size() < 3) {
            if (fallbackCandidates.isEmpty())
                break;
            RunT run = fallbackCandidates.remove(0);
            candidates.add(run);
        }

        return candidates;
    }

    public long getEstimatedDuration() {
        List<RunT> builds = getEstimatedDurationCandidates();

        if(builds.isEmpty())     return -1;

        long totalDuration = 0;
        for (RunT b : builds) {
            totalDuration += b.getDuration();
        }
        if(totalDuration==0) return -1;

        return Math.round((double)totalDuration / builds.size());
    }


JAVA home give me wrong value on Jenkins node I have Jenkins node with below configuration for JavaPath:

/usr/java/jdk1.8.0_131/bin/java

I wrote a simple Jenkins job which does the following:

#!/bin/ksh
echo "JAVA_HOME=${JAVA_HOME}"
echo $PATH

for some reason, the output I'm getting is:

JAVA_HOME=/usr/java/jdk1.8.0_31

why it doesn't use the value which used to load node?

Got response from SO forum: Is there a JAVA_HOME configured under Mange Jenkins -> Global Tool Configuration -> JDK? You may have to click on JDK installations to be able to see what's configured there.


Service to service communication - through proxy or direct? A common scenario is two or more services behind a reverse proxy, typically each deployed in a container:
| service 1 |          | service 2 |
           \            /
            \          /
             \        /
             | Proxy  |

Now the two services want to talk to each other. What are the pros/cons of:

Talking directly to each other?
Going through the reverse proxy?

Is there any standard best practice? Any potential security concerns?

The question is: why use a proxy to communicate both applications? What is the point or target (support SSL, security, availability between services?
In any case, you need 2 proxies, one in each app, in front of each application, it is the best way to use it.
You can also use tunnels, like SSH tunnel or Stunnel that support TLS


Which SCM tools does Jenkins support? I'm aware that Jenkins supports Git and SVN. What other SCM tools does Jenkins support?

It supports AccuRev, CVS, Subversion, Git, Mercurial, Perforce, Clearcase and RTC.

For all of them exists a plugin and as you probably already know, Jenkins is not limited to only that list, anyone can create a SCM plugin for other options if they want to.

Here is the link to the plugins:

AccuRev: https://wiki.jenkins-ci.org/display/JENKINS/AccuRev+Plugin
CVS: https://wiki.jenkins-ci.org/display/JENKINS/CVS+Plugin
Subversion: https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin
Git: https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin
Mercurial: https://wiki.jenkins-ci.org/display/JENKINS/Mercurial+Plugin
Perforce: https://wiki.jenkins-ci.org/display/JENKINS/Perforce+Plugin
Clearcase: https://wiki.jenkins-ci.org/display/JENKINS/ClearCase+Plugin
RTC: https://wiki.jenkins-ci.org/display/JENKINS/Team+Concert+Plugin


How to create named volumes in Kubernetes? Several named volumes have been created in docker-compose. How to create these in Kubernetes?

How to transform the following named volume example defined in docker-compose to kubernetes format

version: "3"
services:
  x:
    image: z
    volumes:
      - a:/path/inside/container
  y:
    image: c
    volumes:
      - a:/path/inside/container
volumes:
  a:

k8s have documentation page about volumes and their types https://kubernetes.io/docs/concepts/storage/volumes/

So in short you need to define spec.volumes and spec.containers[].volumeMounts like:

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}


Advantages of using Code-pipeline and Codebuild for CI/CD over Bitbucket pipeline? What are the advantages of using AWS Codepipeline/code build for our pipeline over the bitbucket pipeline. ?
Some of the factors that I can think of:

Pricing?
Pipeline for a serverless application
integration with AWS
services
Speed of execution

A bit too long for a comment, so converting to an answer:
That's super broad and highly depends on your final needs IMHO, if you're full AWS and ok with being vendor locked down, then code commit/code build/code pipeline is great as it's nicely integrated now.
If you have needs outside pure AWS services, that may get harder, for exemple if you plan on stretching on multiple cloud vendors in a always on DRP (Disaster Recovery Plan), that's probably not the better tool.
My take is that for a full AWS things, AWS products are good and usually soften the edges, but if you need to interact with things out of AWS, there's solution more aimed at CI/CD like Bitbucket, as you said but that'd be my last choice, CircleCi, Travis, Github Actions and Gitlab.
The CI/CD cost is rarely a concern, even if you have a super large company with dozens of products, the code repository and user management costs will probably out-stand the pipeline costs by a large factor unless you run thousands of pipelines per day.
My personal preference goes to Gitlab for its versatility in pipelines, how easy internal runners are to setup and to avoid vendor lock down on the hosting.


How do I hire a good DevOps, fitting my company? Good developers should fit rule 11 of the Joel Test:

  Do new candidates write code during their interview?

However, I know little to nothing about Docker containers, how to configure Jenkins or AWS, etc. What would be a good way to test if the person who applies can manage such tasks?

Sub-questions: I believe that a good devops employee can configure the build chain once and it should work from then on out. Can I then also expect him or her to be a developer in the company (DEVops)? As DevOps is a relatively "new" job, is it maybe better for small companies to share a devops employee or hire him or her as a freelancer whenever you need him or her?

My confusion about the term originates from job offers like this, even here on stackexchange (= link where above screenprint was taken from).

I found this helpful, but possible opinionated article you might want to read if you stumble on this question: https://hackernoon.com/devoops-some-common-anti-patterns-1850ac2f5074

It is a common misbelief that “DevOps” is a role in a company. The word merely denotes an organisational shift in software companies, this shift can be shortly described by the “You build it, you run it!” coined by Werner Vogels:

There is no need to distinguish between building and running, and according to Werner Vogels, it is much better than that:

Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.

This lesson is interesting, but this particular change in an organization is not always easy to implement.

This shift is concomitant of an increasing importance of continuous integration and deliveries methods. Please note that these ideas are much older than the formalisation of “agile” methodologies, some of them are already present in the NATO Scientific Committee report about software engineering published in … 1968!
While the wording can be overlooked, the short description of the DevOps proposal (this site) mentions “software engineers”:

Beta Q&A site for software Engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure.

Now if you are looking for a software engineer that can help your team getting started with these methodologies, engage them on this topic. Even if you are not familiar with this topic, following the “You build it! You run it!” slogan you can start from a programming problem and lead the interview towards question about deployment and maintenance of the application.


Make TeamCity see test results in real time using Maven, JUnit 4 and Surefire So we have a TeamCity with numerous JUnit 4 test suites builds configured.

The problem: Tests tab is only populated after build is complete. If build crashes, tests tab is not populated, even with tests which completed before crash.

The reason for that is Surefire reporting the following to teamcity:

##teamcity[importData tc:tags='tc:internal' type='surefire' path='.../target/surefire-reports/TEST-*.xml' whenNoDataPublished='nothing' logAsInternal='true']

So TeamCity cannot know the state of tests until suite is done and XML file is written.

Now, TeamCity supports real-time tests reporting with messages such as

##teamcity[testStarted name='MyTest.test1']
##teamcity[testFailed name='MyTest.test1' message='failure message' details='message and stack trace']
##teamcity[testFinished name='MyTest.test1']

However, Surefire (the framework responsible for running JUnit tests in Maven) does not output such messages by default.

So it seems that I have three choices if I want tests to be reported in real-time:

Configure a RunListener for JUnit/Surefire to output these messages for TeamCity. Obvious problem here is that I am reinventing the wheel here. I'm also not sure that my reporting of tests will closely match Surefire's reporting of tests in XML file, which may lead to glitches and duplication of tests.
Change my tests to emit these messages. Easily doable since I have a common superclass for almost all tests, but reinventing the wheel is still there, as well as mismatch with XML.
Find a way to either configure Surefire to output these messages, or make TeamCity talk to SureFire to enable their output. I recognize that Surefire is hit-or-miss thing, but this functionality is so popular I expect it has some solution.

Please help me choosing between these options. I have tried googling, the results are very poor.

So I have choosed implementing my own RunListener. I added a compile,test dependency on it to all my other modules and hooked it up in maven surefire plugin configuration. See also https://stackoverflow.com/questions/61206966/surefire-only-reports-first-test-suite-from-module-to-runlistener


Should performance tests be run using a CI and how often? There are tools that test the performance of applications, like gatling. It is possible to run such a test once in a while, but in practice is is not run periodically. We were discussing how to run it regularly and add it to every build, but the CI was getting slow. On the other hand it is important to know if a code change decreases the application performance.

I will assume by CI you mean one integration server. The best way to get the maximum out of your tests and environment stability is to decouple environment per test type. The best example is production which is lively "tested" by your users.

Be aware that by environment, I mean the server or servers used to deploy a specific version of your application or applications (I will refer this as the build). In such emvironment, you would tipically have similar setup as your live/production environment. Based on your team restrictions, here is what I proposed:

Restricted from having a new environment

Simply schedule a job to start load testing when the traffic is minimal. This is usually at night. Upon test completion, a report should be available and granular enough to indicate where improvements are required based on your internal NFR threshold.

No restriction on having another environment

Create a new environment for load tests
For each new build, if it was successfully deployed and/or tested in the CI server, deploy to the new environment
Run the load tests and save the results. Depending on your CI tool, you might be able to configure reports and alerts according to your results quality

In both case, you will need to specify your load test suite in a way that allows you to figure out where latency is too high. I would personally suggest you the second solution. Though it requires more setup and maintenance, it is the most benificial for the following reasons:

Tells you exactly when the build starts to be unstable. For the first solution, you might need to investigate  because a lot of change is happening during the day.
High visibility on what/who made the system slower. At this time, the teams are aware of the issue and can remedy right away. The nighly job might be overlooked on the long run.
Can serve as a performance gate where all builds with a certain response time will stop from going further (i.e. production) until the response time is improved. This is unpractical to put in place with a nightly job. Also, you would need to wait a day to see the result of an improvement or run the test manually.

If you are in the journey to CI/CD, fast failures is prefered as delayed failures. Losing a day to fix a problem can have considerable impact on your time to market.


Setting up Jenkins and git-server on same server I want to setup a Jenkins and git on the same server.

What I am trying to do:

I want Jenkins to be able deploy a folder to another server which runs IIS server (which is running .net).
I don't have code as I bought the product the client provides me with . It's just a publish folder or the executable files which I directly put on the server .I will be using git for version controlling.

  I want jenkins to periodically check the git repository and when it finds any changes, it deploys it over to my remote server which is running IIS and rename the old folder on git with date wise.

How should I go about implementing this?

Thanks in advance for your suggestions.

For me I use jenkins in docker with git plugin.

The Git plugin will give you the ability to check the Git server every specific period of time or you can use git hook from github or bitbucket to trigger the task when ever any change happened to the repo or the branch.

For deployment, most of time I use shell build step to execute some shell command on remote node.


How to remove the AWS Backups I'm using AWS Backup to create snapshots of my production server. My current backup plan has infinite retention and that ran me into gigabytes of storage.
What would be the best way to fix that? I saw I can't remove the backups in bulk (can only select and remove each single backup, but I have 100s).
Is it possible to modify the backup rule so that it removes the previous backups? Or is there a way to select and remove all the backups done by AWS Backup?

Coincidentally I had to do something very similar yesterday. This is the script I used:
#!/bin/bash -e

VAULT_NAME=...   # put your Backup Vault name here

for ARN in $(aws backup list-recovery-points-by-backup-vault --backup-vault-name "${VAULT_NAME}" --query 'RecoveryPoints[].RecoveryPointArn' --output text); do
  echo "deleting ${ARN} ..."
  aws backup delete-recovery-point --backup-vault-name "${VAULT_NAME}" --recovery-point-arn "${ARN}"
done

You can also add --by-created-before to delete the old backups only.
Hope that helps :)


Start dev with purely docker, or something like vagrant (in a to-be-dockerized application)? I have a Ruby on Rails application that has been around for a while, and implemented completely classical, so far. Everything is fine; but since the number of environments we are deploying to (testing, QA, several production envs) have grown, I decided to dockerize the thing.

A side effect should obviously be that new developers get on board quicker.

At the moment, I have made a Dockerfile to build the application and run it; I am happy, everything is fine. I am now pondering how to move on:

Either make it so that the tests can be run by a simple docker command as well - so that the daily development loop simply consists of edit-rebuild-run-tests (or, for that loop, we'd probably rather just mount/bind the sources that are actually being edited by the dev outside of the container, so we save the explicit "rebuild". Nothing needs to be precompiled etc. for running the tests anyways.).
Or use something like Vagrant to streamline the development environments, and don't really use docker for the actual edit-test cycle.

I am strongly tending to the first option (i.e., KISS), but I have little experience working with this. I can't really speak on the second as I have no real experience with any of those tools like Vagrant that focus on the developers perspective.

The other developers have no particular experience with any of these tools, so whatever I pick/suggest should better be pretty non-invasive. Everyone has their happy, well-configured VM to develop in, so far. We don't really encountered any problems with developer VMs diverging, or something like that (this being Ruby, after all).

Questions: is there anything wrong with going for my first scenario? Are there huge benefits introducing something else aside of docker at this very early stage of our team digging into DevOps tools?

Vagrant, in this case, would simply add a lot of unnecessary overhead into your testing environment. You can create containers that quickly test specific groups of functionalities and paste the results somewhere. Your team won't spend much time learning how to start these containers as it is usually a simply command. Most of changes are going to be done inside the code, not into the testing environment. But if you need to change the test environment, the Dockerfiles must be in an easy to access place. You could also automate the build process of containers linking the Dockerfile (e.g. from a GitHub repository) into the DockerHub or Store.
I can't see a reason here for not going into Docker. This knowledge will be more usefull for your team than Vagrant skills.

You can read more about it here: https://stackoverflow.com/questions/16647069/should-i-use-vagrant-or-docker-for-creating-an-isolated-environment


How to avoid build scripts duplication Let's say you've got several code repositories on GitHub. You want to build, test and deploy them. You picked a continuous integration service (e.g. Travis CI, AppVeyor or something else) and wrote some scripts for building, testing and deploying.

If your projects are very similar, let's say all of them written in Golang, the result of the build is always a Docker image and deployment is always a push to Docker Hub, you don't want to duplicate the scripts across all of your repositories. How would you avoid that?

You could extract the common, shareable portions of the scripts which you'd package as either standalone scripts or libraries (depending on the scripting language you use and/or preferences), placed in a shared location (of course, backed by their own repository).

Then, in the scripts from your code repositories you'd replace the extracted portions with invocations of the scripts (or calls into the libraries) from the shared location.

Some CI/CD tools might be capable of directly invoking the scripts from the shared location, so if there aren't any specific portions in some of the code repo scripts you could drop them completely from those repos.


Is GitLab flow (or GitHub flow, etc) anti build-once deploy-everywhere? Historically, especially in the Java world, build-once, deploy everywhere has been a very big thing for deployments.  Artifacts should be built exactly one time when a release is made and stored somewhere like Nexus or Artifactory where they are immutable and can be deployed to all environments, repeatedly and safely.

GitLab flow, on the other hand, seems to recommend having a branch per environment and deploying to that environment as an event upon doing a merge request to the branch.  E.g. a master -> staging merge runs CI/CD on the staging branch, resulting in a deployment there.  Merging the staging to the production branch does the same in production (with the possibility of forcing a manual agreement to the run).

So, GitLab flow causes us to rebuild our artifacts for every environment rather than build once deploy everywhere.

Does this mean we should totally ditch build-once deploy-everywhere when moving to modern tools like GitLab/GitHub?  Is that a good thing?

I guess we can augment GitLab flow by:

Build artifacts on merge into DEV branch and store in a maven/etc repo.
Do deployment using those artifacts.
Have merges to staging/prod skip build/test and only do deploy using the same artifacts.

This seems like forcing GitLab/etc to do something against their model though, so I'm thinking its not a good idea.

Note: I also am wondering how building/testing/deploying in every environment separately is possible in some large projects.  E.g. Facebook's presto has like an hour of tests in a maven build (or more)... I wouldn't want my production release taking hours; that's the opposite of modern.

Any thoughts here?

One possible answer could come from the reason for using multiple branches as basis for environments in the first place.

In some organisations (typically for large scale projects and often for historical reasons) it is desired to allow for cherry-picking hot fixes in each environment to limit the amount of changes (thus the risk) picked up in each iteration on that environment. I'd argue that such approach is not really aligned with continuous integration/delivery at the project level (it may be at each of the branch levels).

In this context the branches will diverge, so build-once, deploy everywhere principle is similarly applicable only at the branch/environment level, it cannot be applied at the project level. The GitHub/GitLab flow could work well in such case.

If, however, there is no cherry-picking between branches and strictly straight/fast-forward merges from upstream branch refpoints are used to propagate changes to the downstream branches/environments then the reason for using multiple branches is IMHO questionable. A single/master branch can be used instead, the environments being implemented simply as different steps/stages in the CI/CD processing pipeline.

The pipeline would be triggered on the branch tags/refpoints from which the original change propagation would be initiated in the multi-branch scenario (ideally for each and every commit).

The build-once, deploy everywhere principle can easily be enforced in this approach, which aligns very well with continuous integration/delivery/deployment at the entire project level. You just need to consider each build as potential release candidate from the very beginning of your pipeline processing.

Note that nothing in this scenario conflicts with using GitLab/GitHub (or any other modern version control system) itself, you just don't have to use all the features they offer ;)


Why not use configuration management tool instead of Dockerfile? I'm pretty new to Docker and configuration management tools.

At first I started writing bash scripts to provision my Vagrant boxes for my development machines, but now I've switched to using Chef for that so that I can use the same source to provision both development and production environments to try and get them as similar as possible.

Since I've started using Chef I've come to enjoy the DRY aspect of not having to copy and paste shell script lines from project to project, the ability to provision machines running a variety of linux distributions using one consolidated source, and the convenience of using community provided cookbooks.

Now that I've been using Chef to provision my vm's it feels like taking a step backwards when I am adding RUN commands followed by shell commands to a Dockerfile to achieve what could be achieved by just running a Chef recipe.

I've googled and haven't found anything (but maybe I just missed it) but it doesn't look like there is an easy way to use Chef recipes to build Docker containers. Why is that?

I understand that containers are meant to be immutable and configuration management tools are commonly used to re-configure machines during their entire lifespan, but wouldn't they still offer a lot of benefits if used during the initial building of the container?

The tool you need is Packer using Docker as the "builder" and Chef as the "provisioner". Then you can add the resulting image to your repo and reuse it without having to pack again, until your recipes change.


Are configuration management tools appropriate to use as deployment tools? Off the back of my answer to the question: How can DevOps help to improve Software Escrow procedures? Tensibai had the question:

  What would necessitate Capistrano on top of puppet or chef?

My response was to post a link to Noah Gibbs' article "Do We Need Both Capistrano and Chef?".  Personally, I still subscribe to Noah's view that it is most appropriate to:

use a specialist deployment tool such as Capistrano for deployments.
use a specialist configuration management tool such as Chef for configuration management.

The fundamental approach that each type of tool uses to complete its task is very different:

Configuration Management Tools - are about creating and maintaining the desired state of a system, they are inherently idempotent in nature. Examples of configuration management tools are Chef, Puppet, Ansible, PowerShell DSC, Salt Stack.
Deployment Tools - are about delivering versions of software into a hosting environment, they provide functionality to maintain multiple versions of the software on multiple machines and manage which version is "current", they are inherently imperative in nature.  Examples of deployment tools are Capistrano, Octopus Deploy, Deployer and Command.io.

I do believe that Configuration Management Tools can do the job of deployment tools and in the case of Immutable Infrastructure they are the most appropriate tool for the job as software versions on the target don't need to be maintained.

Question: Have configuration management tools such as Chef, Ansible and Puppet matured to the point that they are capable of fulfilling both the idempotent and imperative models?

In such context the typical advice should be immediately applicable: use the right tool for the job.

But then you also cannot ignore nowadays the almost virulent tendency of software tools to extend functionality into more or less related fields and actually become toolsets for various reasons: cool feature(s) to have, expand customer base, amass more revenue, etc.

For example many file management tools include image viewing features and many image processing tools include file management features. You can move files around and you can view images with either of the tools, often equally well.

Because of this it's quite possible to have entire portions of the software development process covered/overlapped by multiple tool(sets) even if their main feature/capability differs.

So it really boils down to the exact functionality you want to achieve in your particular process and how well one tool or the other does the job in your context. Subjectivity/preferences/convenience included.

Making this question primarily opinion-based ;)


Triggering a SNS notification when an object is accessed (downloaded) in AWS S3 I have managed to trigger events on my bucket when objects are uploaded (PUT) but I am surprised that there are no triggers called when objects are downloaded (GETs), as can be seen in this screenshot of the interface:

I want to be notified of each download so I will be able to limit the downloads of any given object to a maximum of 10 times.

How to do that?

I am aiming at setting a tag named for example limit_reached, value: true on the file object if the download limit is reached and returning 403 by conditional access policy based on the limit_reached tag.

Alternative to all this, is to generate signed url's by my web application and track how many signed urls have been generated for a given object and denying any further after generating signed urls 10 times.

Your ideas are highly appreciated.

As you point out, AWS S3 currently does not have an event type for GET calls.

To do something similar to what you are trying to do, I had to do the following:

Create an application/lamdba that's only purpose was to retrieve items from the S3 Bucket.  This application was given exclusive privileges to the S3 bucket.
The application keeps a counter of the number of times that S3 resource has been accessed.
The application returns the 403 or whatever you want if you exceed the download limit.

Basically create a "middleware" that's sole purpose is to go from your website/application to S3 and track the number of requests.

While the above solution meets your requirements, it is vulnerable to common attacks such as DDoS or people spoofing their IP.  If you take this approach consider additional security measures (e.g. only authenticated users can invoke the application's GET call to S3).


How to access report data from Sonarcloud.io aka SonarQube API, or functionality no more available? Thanks to SonarCloud.io, you can perform static code analysis without own infrastructure.

But, is there an API to access data shown in Sonar dashboard?

What I can find so far, is the "Sonar Web API" documentation but it looks very scarce. There are also docs for older version, but API documented there seems to be no more available.

Is there more "hidden" API functionality? I can't see it mentioned in the Enterprise edition.

Ok no so obvious but at least one possible way is:

Note the component ID in the TravisCI report
Use the ID and this documentation to get data:

https://sonarcloud.io/api/measures/component?componentId=&metricKeys=code_smells


What are the different job permissions possible in Jenkins, and what are the reasons you would use each? I'd like to understand better job permissions in Jenkins. What type of user permissions can I setup in Jenkins? And when would you use each?

There are 4 type of user permissions in Jenkins:

Open

Jenkins is accessible for everyone with no permissions. Basically anyone can do anything. This should be used for internal use only.
User authentication (all admins)

All users are admins. The authentication method can use Jenkins’ own user database, LDAP, Unix user/group database, servelet container (e.g. Tomcat or Glassfish user DB) or other authentication plugins. This can be used when there is no need to restrict users from doing certain actions.
Matrix based security

This is a global permission per role/group security strategy where each user where permissions are associated with groups to which users belong to. This is the most common authorization to use for multiple users.
Project based matrix

It is authorization strategy where user permissions can be configured per individual jobs. Once activated, permission matrix can be activated on each job page. Useful when specific jobs shouldn't be accessed by certain users.

Related page: Securing Jenkins - Access Control.


Kubernetes and Jenkins I started building CI/CD pipeline using two Kubernetes clusters and one Jenkins. Two clusters are totally isolated as one is in the test environment and other in production.

After searching from many blogs, I come up with these approaches:

Setup Jenkins master in production and one Jenkins slave/agent in the testing environment.
Make Kubernetes api-server of test environment accessible in production environment with proper firewall whitelisting and setup jenkins in production to deploy in both environments.

I like to know which approach is better.

For the best practices will be great to install Jenkins master on the lower Environments (best Dev env) and to leave Production in peace with only necessary things (with your end-user application and their dependencies).

The reason why is because production means production and if something will happen with Jenkins or if you will allow a lot of people accessing Jenkins in production you increase your failure rate.

Will be better to install Jenkins separated from production and to do VPC Peering between clusters and after you can create a fully CI/CD pipeline where you can create a Jenkins slave/agent which will deploy your application to PROD.

PROD suppose to be more focused to an end Product result.
You didn't specify which cloud provider do you use so, I can't help too much...
Hope this will clarify your vision.


Docker compose volume syntax valid for Windows and Linux We have developers working on an app using both Windows and Linux. The application is built within a Docker container, and ships a docker-compose specification for the build environment.

The local directory is mounted as a volume:

    volumes:
      - ${PWD}:/tmp

however this doesn't work in Windows because $PWD is not defined.

My question is:

Can we have a single docker-compose.yml to satisfy both the Windows and Linux developers?

The obvious way to do this seems to me to have two docker-compose files, one for each OS.

Yes.  Just use ./ for you current directory that the Docker-compose file is in.  Docker-Compose does not allow you to use a context that is located above the compose file, so everything the compose file will use is below the folder with the .yml.  Your "working directory" for the compose file is just "./".  If you are trying to set a directory below that it would look something like: volumes:
  - ./DirectoryIWantToTarget:/tmp

There's an example of this in the Docker-Compose documentation here.  This approach makes the solution cross-platform as well.


How can I test native macOS UI software in a container before deployment? As part of the CI setup, I'd like to run (automated) tests on native macOS GUI software in a 'safe environment' (i.e. without messing with the host software installation too much). Virtual machines (using VirtualBox) work in principle, but they are fairly slow to start/stop and VirtualBox on macOS hosts doesn't seem to be very stable (it works great on Linux hosts though).

After reading macOS testing on Desktop: Docker containers vs. Homebrew installation I learned that using Docker works great for testing software on macOS. However, my understanding is that even with Docker Desktop for Mac (which uses Hyperkit to virtualize the OS as opposed to running VMs using VirtualBox), the software running in the container sees a Linux installation.

Would it be plausible to use Docker anyway (maybe I misunderstood it?) such that the containerized program sees a macOS installation or would some other solution (A plain chroot?) work better here?

I can confirm that running Docker on Mac works just fine, but according to this ServerFault question, it's not possible to just run MacOS in Docker.

(You might be able to run MacOS in a VM in a Docker container, but that's probably not what you want.)

You could purchase a MacMini, use it as a Jenkins slave and run automated tests on it as part of your build pipeline or something like that?


Build isolation - Docker container based builds in Bamboo 6.4.0 Finally, it is possible in Bamboo to let a build run in a Docker container without dealing with agent configuration.

The system just asks for a image.

Now, what about the underlying infrastructure, what happens there?
Will then Bamboo server host just spawn containers locally (which limits horizontal scalability)?

Yes, you are correct. Bamboo will spawn the build containers on the agent that the build is running on (either Local, Remote, or, Elastic - depending on your configuration).

In order for this to work the agent will require Docker to be installed and running.


docker build fails on one machine but succeeds on another On my own machine (Windows 10, Docker Desktop 2.1.0.3) the build succeeds and runs.
On another machine (Ubuntu 18.04, docker CE 19.03.13) the build fails with the error shown.
Why does the build work on one machine but fail another?
dockerfile:
FROM ubuntu:latest AS toolchain
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y \
  build-essential \
  g++-5

error:
Package g++-5 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  gcc-10-test-results gcc-9-test-results gcc-8-test-results gcc-7-test-results

Package 'g++-5' has no installation candidate
The command '/bin/sh -c apt-get update && apt-get install -y   build-essential   g++-5' returned a non-zero code: 100

The problem seems to be that the ubuntu:latest image is stale.
Changing to ubuntu:bionic fixes the issue:
FROM ubuntu:bionic AS toolchain
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y \
  build-essential \
  g++-5

I don't know why an old image is being used, but that seems like a separate question.


Referencing locally built Docker images in Terraform Is it possible to use docker images in Terraform that are not hosted in a registry but in the local Docker storage?

I'd like to have a resource like the following where no pull is performed on the image if it exists locally.

resource "docker_container" "my_service" {
  image = "my_locally_built_image_name"
  name  = "my-service"
}

Yes, As we write terraform template is correct.
When you use terraform apply it will check local docker image list if it doesn't exit it will go to find registry as you define docker image.

If you don't want a pull image from the internet you can try the below steps. But at least you should have a base docker image of any Linux distribution.

Create a Dockerfile.
Build Dockerfile as below command

# docker build -t image_name -f Dockerfile

Define the docker image as a template

resource "docker_container" "my_service" {
  image = "image_name"
  name  = "my-service"
}

By terraform init install terraform module and apply the terraform template.

# terraform init

# terraform apply -auto-approve


Cross region replication of Redis Docker container data I am looking for some help with figuring out a way to take a Redis Docker image and then do near real time replication of the data to another server maybe over an SSH tunnnel.

I need this to be able to go onto a Ubuntu 16.04 LTS VM/docker host, reason for this is OS limit is that the Redis Docker container is only a small part of our setup/application and the other major parts are not tested on anything else.

I was doing some reading and Redis itself has replication, but I am not sure if this is the best way to go about doing it.

We do have an SSH tunnel set up for another database sync.

How could I do this properly? The whole point/idea of this is that we need a DR plan and this factors into it.

My best idea so far has been a rsync between the two servers I need the data on, though I know that is not a good solution and want something a bit better.

You don't mention orchestration, are you planning to implement all by your own configuration on top of Ubuntu?

I recommend you that take a look at Kubernetes and StatefulSet workloads

https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

You can use Ubuntu as your host to accomplish your needs, but in my experience, you can only need to define correctly your workload and open the right ports to communicate and with the kubernetes integration on different providers you have the persistent volume easy to manage.

Also, I recommend you to review Helm and you have a redis-ha chart ready

https://github.com/helm/charts/tree/master/stable/redis-ha


How should we organize VSTS repositories? We are a small company with the following systems:

External Web Site for pre-customers (already created in ASP.NET Framework),
External Mobile Application for customers (in progress in Flutter),
Internal custom CRM that work on items collected by this External Web Site and Mobile App (already created in ASP.NET Core),
Internal DataBase and REST API Server (already created in ASP.NET Core this will NOT be changed in a long time).

So External Web Site and Mobile App talks to Internal Database by API, and then Internal CRM uses this API to retrieve data collected by those External Systems. We are moving from mono repo in Subversion to GIT in VSTS.

How should we divide projects into the repository?
Should we have one repository to manage all products and then later build CI/CD configured to release few projects at once? This will be easier to run development on a single machine with API running in the background. Or should we have few repositories with Test environment to manage API and Database version? This will require setting up an additional server for Web API and Database.

I am asking from a project manager and developer perspective what will be easier and more convenient to use and manage?

From the perspective of build automation, I find that it is better to have multiple repositories.  This allows for smaller configurations and more granular control of your build/release process.  You can allow references and pull in source code to build or release (of course you can also ignore source code as well in VSTS build pipeline).

This leads to being able to release just the project you want or need to your desired environment.  You can, of course, pull in artifacts from other builds and include them in your release if you need to.

To summarize, I tend to go as small as possible and only group things into the same repository if they are indeed part of the same project and no part of the project can be used elsewhere.


kitchen verify hangs on centOS, but not Debian .kitchen.yml

---
driver:
  name: vagrant

provisioner:
  name: chef_zero

platforms:
  - name: debian-9
  - name: centos-7

suites:
  - name: default
    run_list:
      - recipe[foo::default]
    verifier:
      inspec_tests:
        - test/integration/default
    attributes:
      foo:
        sshd:
          port: 22

cmd: $ kitchen verify

debian-9 finishes just fine, no problems.
centos-7 just hangs and hangs.

I don't believe it's the tests. They are standard inspec control checks. If I comment out the tests, the same thing happens.

Any idea what could be happening here?

format: documentation output:

Finished in 0.75833 seconds (files took 0.90276 seconds to load)
30 examples, 0 failures, 1 pending

       Finished verifying <default-debian-9> (0m1.91s).
-----> Verifying <default-centos-7>...

Nada. The "1 pending" is just a check that has been ignored due to OS detection.

This was working earlier today and stopped working out of the blue. I tried destroying the vagrant box.

I also had this problem show up.  I think it's related to SSH.  I was writing a custom sshd_config.  Vagrant login's were slow after the first converge and verify was taking forever.  Removing the sshd_config stuff from my cookbook fixed the verify and slow logins.

Maybe it's not very helpful, but it's a place to start looking, anyway.  Short term, I hacked it together:

unless ENV['TEST_KITCHEN']
  cookbook_file '/etc/ssh/sshd_config' do
    source 'sshd_config'
    mode '0644'
    notifies :restart, 'service[sshd]', :delayed
  end
end

Jye


Recommended JFrog Artifactory Layout setup for Maven Projects We are very new in using Artifactory services, we would like to store all our artifacts in JFrog Artifactory server for dependency as well as for release management. I have currently created one Local Repository in the name 'myartifactory' and I am planning to use the following code in my projects pom.xml file for distribution management.

<distributionManagement>
    <repository>
        <id>central</id>
        <name>jd-releases</name>
        <url>http://jd-msg.staging.com/artifactory/myartifactory</url>
    </repository>
    <snapshotRepository>
        <id>snapshots</id>
        <name>jd-snapshots</name>
        <url>http://jd-msg.staging.com/artifactory/myartifactory</url>
    </snapshotRepository>
</distributionManagement>

Does the above method looks like a recommended way? How about having "Remote Repositories" and "Virtual Repositories"? Is it mandatory to have? What is the real life example for those?

In addition artifactory by default recommends some best practices for Local Repositories like the following,

Pre-defined Local Repositories:
- Artifactory comes with a set of pre-defined local repositories, which reflect best practices in binary repository management as follows:

libs-release-local - Your code releases
libs-snapshot-local - Your code snapshots
ext-release-local - Manually deployed 3rd party libs (releases)
ext-snapshot-local - Manually deployed 3rd party libs (shapshots)
plugins-release-local - Your and 3rd party plugins (releases)
plugins-snapshot-local - Your and 3rd party plugins (snapshots)

So I am bit confused about the right approach. Suggestions are welcome.

Within Artifactory there are three types of repositories:

Local: Local repositories are physical, locally-managed repositories
into which you can deploy artifacts
Remote: A remote repository
serves as a caching proxy for a repository managed at a remote URL
Virtual: A virtual repository (or "repository group") aggregates
several repositories with the same package type under a common URL.

Local and remote repositories are true physical repositories (they exist either on your server on on a remote server somewhere else), while a virtual repository is actually an aggregation of them used to create controlled domains for search and resolution of artifacts.

If you need all of those types depends a bit on your use case. A real world use case for a remote repository would be Maven Central or jCenter where developers host their Maven packages. JFrog Artifactory can serve as a cache for those services so that not every call to resolve Maven dependencies has to go through the Internet. A real world use case for a virtual repository is that I have a remote repo (like the ones I already mentioned) and a few local repos too (like the ones you mentioned in your question). I want to make sure that my developers only need to configure one Maven repository as URL and my virtual repository allows me to do that. With a virtual repo, I can group together all sorts of other repositories and give one URL to developers so I can manage which dependencies are allowed as opposed to resolving them from the Internet every time.

Based on lessons learned we've included some default repositories into Artifactory that follow the flow of most developers that use Maven. Having said that, there is nothing stopping you from adopting your own workflow and not using the default repos.