What is the purpose of running PHP-FPM in its own container instead in the same container as apache2/nginx?

Im heavily investigating this, and like many people, im discovering that in 2020 there doesn't seem to be so much logic in separating tightly coupled webserver + PHP + app process/code from each other:
Two main arguments for separation are scalability and separation of concerns (one process per container).
Logically the webserver should only act as webserver and distribute traffic to PHP nodes behind a service that uses a LB.
This way one container/service serves webserver purpose and serves static files, while proxying the php requests to the php pod which only concerns with PHP.
And webserver and php pods can scale differently - ie you may need 50-100 PHP pods for a workload, but only 3-4 webserver nodes. So you save on resources. Great!
Except in respect to separation of concerns...
If the webserver is not going to serve requests to different apps, there is little logic for separation of concerns to different containers - leave aside services. If the app is coupled with the webserver, you just end up spawning extra webserver pods, with accompanying service and load balancers to go with them.
On top of that you will have to distribute the app code to both containers or mount them from a NFS bind, or non NFS mount. You will have to deal with all the relevant access and permission stuff, if you put the app code in both pods you will have to deal with static + dynamic file separation, or even end up having to distribute both type of files to both pods. You could put two containers and make one of them mount directories on the other and that would work, but that actually puts two containers in the same logical host in regard to network, host etc so you are still combining them. This still provides some separation of concerns though. But the communication in between the two containers in the same pod is a concern - it has to either happen through intra-host network over loopback, which uses network stack and is less performant. Maybe sockets could work.
Even worse if your app may require webserver being present in the same container - for example if you are doing ssl termination and have to carry over the visitor's actual ip to the php pod, you may end up having to jump through some hoops. While both webserver and php are available in the same container, this can be done through various means.
When everything is in one container, none of these is necessary. Everything is neatly packed in the same place, no need to track different deployments, services, app codes, replication controllers.
This kind of singular container/deployment is very advantageous today especially if you are using ingress-nginx or nginx-ingress and hosting many different apps/sites in the same cluster. Each app/site is contained in its own container (imagine different WordPress sites), each site is completely contained in its permissions, access, deployment, version, requirements etc.
So much that you could even allow apps/sites to customize their runtime environments by providing configuration files for webserver or php from NFS shares or other mounts - ie .htaccess, php.ini etc. Which is a must for hosting different apps since people tend to have different requirements.
In respect to performance
Today NGINX or Apache require very little resources with event based request handling. For example in my benchmarks, i saw Apache 2 with event mpm requiring only 3-4 MB memory, and a grand total of ~2-3% cpu (out of 1000m requested cpu, ie 1 vcpu) while handling 50-100 concurrent requests per second while serving WordPress.
The weights of webserver vs PHP pods would differ depending on the app or website of course, and there could definitely be apps which would require such a separation, but for most common web workloads this does not seem necssary.
So spawning a few Apache pods and then spawning hundred or more PHP pods does not seem to bring much gain. Aside from creating internal cluster network traffic as pods need to communicate with each other and also you create more complication in the app configurations (deployments, services, load balancers etc).
Another disadvantage of separating containers is that you create two times the services per app. This will reflect on the limits of the cluster you create since services, pods require ip addresses.
When webserver + PHP +app are in the same container, the webserver can just communicate with php-fpm via file sockets. Which is faster, and creates less network overhead even on loopback interface inside the container, leave aside creating network traffic inside the cluster. Internal network and cpu load saved.
In conclusion...
For specific purposes, with one Apache 2 or NGINX server distributing requests to different apps on different PHP-FPM clusters, separating concerns would likely be a necessity.
But in the era of ingress-nginx, this really doesn't seem necessary.
Especially reduced complexity, portability, saved performance and internal cluster noise, better customization and other benefits gained from packaging tightly coupled server + PHP + app deployments in one single container seem to be too good to pass.
Furthermore, this even enables shared-hosting like formats in Kubernetes clusters, which seems to open many possibilities.
I would very much appreciate any input from anyone who had experience in dealing with this choice in between selecting singular container for tightly coupled app vs multiple cointainers, or anyone who did benchmarks on these.


Docker compose host variable in extra_hosts not working

I've tried your case, and it works fine on my side:

version: '2'
  services:
    test:
      image: ubuntu:16.04
      command: sleep 9999
    extra_hosts:
      - "${HOSTNAME}:1.1.1.1"
      - "test.com:1.1.1.1"

and here is what I get in the container

cat /etc/hosts
...
1.1.1.1 a1.test.com
1.1.1.1 test.com


you can use terraform to install helm charts, you dont have to obviously
something is probably wrong with your kubernetes connection, check if its actually working


Run:

$ sudo touch /usr/local/etc/ansible/hosts
$ sudo vi /usr/local/etc/ansible/hosts

To create a file and then open it.


Prevent ${PIPELINESTATUS[0]} from being evaluated in Jenkinsfile

There seems to be some syntax issues and also I would suggest to use bash instead if using sh shell.

Try the below code and see if this works properly.
(EDIT - Put shebang on first line to accept as answer)

sh label: 'Stop and Remove Old Docker Container', script: '''#!/usr/bin/env bash
                docker ps -a
                echo $APP_CONTAINER_NAME

                docker ps -a | grep $APP_CONTAINER_NAME || true
                status=("${PIPESTATUS[@]}")
                DOCKERCODE=${status[0]}
                GREPCODE=${status[1]}
                echo "Docker Command Code: $DOCKERCODE"

                echo "Grep Command Code: $GREPCODE"

                if [ $DOCKERCODE -eq 0 ]; then
                    docker stop $APP_CONTAINER_NAME
                    docker rm $APP_CONTAINER_NAME
                else
                    echo "WARNING: Docker command was empty or had an error"
                fi
            '''

In the above code, I have made changes in the way you were trying to get output of command docker ps -a | grep $APP_CONTAINER_NAME || true using PIPESTATUS variable.
Since PIPESTATUS is a special variable, it's value gets updated after every command, so you were not getting any value of ${PIPESTATUS[1]}

The other change I have made is fixing the syntax issue in the line if [ $DOCKERCODE -eq 0 ] then; to if [ $DOCKERCODE -eq 0 ]; then

You can test out the code further.


I think that it's very difficult, if not impossible, to achieve something like this.

The reason is that once the machine running Jenkins is connected to the VPN it is also effectively disconnected from the original network it was connected to, which means Jenkins on that machine will loose connection with the rest of your Jenkins setup.

The only way that might work would be if using completely standalone one-machine Jenkins setups.


Reaching a Docker environment running in VMware from LAN

Docker container port needs to be be mapped to host port to be reachable in VM!!!


How to create slave jenkins given master jenkins?

You could use the EC2 plugin or the ECS plugin if you want to provision agents dynamically. These would provide some environment variables to use when constructing build_id - e.g. :

BUILD_TAG:

  String of "jenkins-${JOB_NAME}-${BUILD_NUMBER}". All forward slashes ("/") in the JOB_NAME are replaced with dashes ("-"). Convenient to put into a resource file, a jar file, etc for easier identification.

NODE_NAME:

  Name of the agent if the build is on an agent, or "master" if run on master

You would have to configure the clouds in Jenkins, assign a label to the templates you want to use as agents, and then request those in your pipeline or job configuration.


Find relevant domain/hosted zone under which to host subdomain

Short answer: I don't believe that is possible.
In my opinion, I suspect this problem has more to do with process and responsibilities than it does with Terraform.
You said:

It's possibly that I could go with the fist approach (e.g. where example.com is my only hosted zone) only for someone to later add a hosted zone for the mysite subdomain. If that occurred I wouldn't want to have to change my code...

Terraform is best when at least most of its associated resources are Terraform-managed. That means you should be managing your zones, too, not just your records.
Which begs the question: why isn't your zone in Terraform?
If your zone was Terraform-managed, the impact of that change should be evident in a terraform plan to anyone who might come along to change it. Even if it references a zone in a different remote state file, a tool like runatlantis.io could show that diff in the Github PR before merging.
Let's say this is the worst-case scenario: you managed the records, it's a different team that creates and manages the zones, and they don't want to use Terraform. In that case, perhaps your DNS records shouldn't be in Terraform, either. Terraform is arguably too stateful for that. Perhaps a few python boto3 scripts can do everything you need it to.


Modelling economic value of risk-reduction DevOPs efforts

You are probably unable to find data on this for two main reasons. Firstly, because it varies from system to system. Does an outage cost you money due to contractual obligations? Or only in lost reputation and in user perception? How much does that cost? This varies from organization to organization. But I think that might be what you are getting at with the Bernoulli variable...

...Which brings me to the second thing. In order for you to be able to model risk, you need research in which someone has already statistically proved or measured the efficacy of DevOps methodologies (which means you have to define exactly what DevOps is first, a notoriously tricky issue.)

You also need to be able to compare that to old methods - meaning that someone must also have measured data for the Dev/Ops segmented model. I'm not sure that research exists or is settled. Probably because the efficacy and cost of Dev/Ops will also vary widely from organization to organization. In that respect it may provide an opportunity to measure the old methodology and then show the average improvement of changing methodologies if you can find enough research subjects.

In short, it is doubtful that such a formula for risk modeling exists. If it does, it likely exists as paid marketing research to a consulting firm and is unlikely to be available to the public and I would personally be very dubious of the accuracy of it's results due to the subjectivity of the input variables measured.


Is it allowed to remove mounted directory from inside Docker container?

No, you sadly can't remove a volume that is in use by a container which is stated under 'Extended Description' here: https://docs.docker.com/engine/reference/commandline/volume_rm/

However, I'd suggest using docker for its strength and restarting the docker container after updating the directory externally.


What part of the Bamboo pipeline should generate a Docker image?

I believe both options are viable routes, but my preference is for Option 1 as I like having the "deploy plan" to be only concerned with starting a container using the built image.


Why does the Jenkins bitbucket-build-status-notifier-plugin post the status to the shared pipeline library repository?

This is a known bug.  See JENKINS-42878 and JENKINS-41996.  This bug has been resolved upstream, which means you should be able to fix the bug by upgrading the plugin to the latest version.


Error with docker-compose - image not supported?

“Image” needs to be at the same level as “build”.


What is the exact use of DETACHED HEAD state in Git?

The "normal" way of working with GIT is by checking out branches. HEAD is a "pointer" to the latest commit in that branch, and GIT will allow you to commit new changes after that pointer.
However, as you figured out, it is possible to check out a specific commit hash, if you want to. In this situation, if you make changes and try to commit them, you will be unable to do so, since you are not at HEAD, and GIT will not allow you to commit your changes.
Most of the time, detached HEAD (checking out an older commit) is used if you want to test how your project ran at a certain point in time.
If you need to make changes to the code or need to build it using Jenkins MultiBranch Pipelines, for example, it is also possible to create a new branch from that specific commit by running:
git branch my_new_fancy_branch 7y8u33ii
or
git checkout -b my_new_fancy_branch 7y8u33ii
... where 7y8u33ii is the hash you provided in the question. For this new branch, 7y8u33ii will be HEAD, so you will be able to commit new changes. If you need to get your code into the branch from which you created this new branch from, you will need to do a merge, but this is another discussion altogether.


I think there is a way to do this on docker:

  As of Docker 1.10 User Namespaces are supported directly by the docker daemon. This feature allows for the root user in a container to be mapped to a non uid-0 user outside the container, which can help to mitigate the risks of container breakout. This facility is available but not enabled by default.

You can map the root user inside docker container to specific user from the host machine (uid).


How to convert a docker-compose file to kubernetes file(s)?

The original and most popular solution I've seen is kompose which does exactly as you are asking, converts the compose yaml file into kubernetes yaml files.

If you want to continue working with a compose.yml file for compatibility with other systems, then docker recently open sourced their compose on kubernetes solution that integrates directly into kubernetes.


How to implement the manual step at the end of continuous delivery?

Personally I consider the distribution of the software to a target just an intermediary step of a deployment - installation/activation of that software being necessary to complete that deployment.

To me the delivery (as in continuos delivery) stops when the software to be deployed is created and made available for deployment (i.e. for distribution, installation and activation)

So, to answer your 1st question, no, I wouldn't consider distribution and installation as reflecting the manual step differentiating continous delivery from continous deployment.

Yes, in some (hopefully rare) cases that manual step is just the final human decision for deploying into production, reflecting the cultural mistrust in process automation and the mental comfort of having a human double-checking and signing off the deployment decision (thus assuming responsability for it) even if that decision is purely made based on an algorithm that can be automated (like counting pass/fail testing results).

But in general it simply reflects the fact that the decision for performing the deployment in production is not simply the result of an automated algorithm. Here would be some example such cases:

the automated decision is overwritten

deployment can be signed off even if not all quality criteria are met (we all know that this is not just a theoretical case)
the deployment is held for whatever reason, even if all criteria is met (due to market timing implications for example)

the automated algorithm is not (yet) implemented/deployed
the algorithm includes checks for some criteria depending on human decisions (say results from manual testing)
deployment is actually done in a 3rd party customer environment, following additional customer checks

So I wouldn't look at the manual step simply as an implementation issue.


What does a "DevOps Transformation" contain?

I need to put my answer to this question in the context of what DevOps is, more specifically within the DevOps transformations I have been part of, DevOps is the ownership of the full Software Development Lifecycle. All of the practices in the chart are an important part of DevOps, and they enable and underpin both Systems Thinking and Amplification of Feedback Loops.

However, the key differentiator between CI/CD and DevOps is the actual operation of software in a production environment, where it can deliver value to its customers and the business it serves.

As a consultant participating in or leading a DevOps transformation I have the following aspects in the front of my mind:

Culture: As Dave quite rightly pointed out a Culture of Continuous Experimentation and Learning is critical to the success of any transformation.  From a DevOps perspective this comes down to how do we engender a culture that is supportive of the chosen DevOps model, this model could be "You Build It, You Run It" or it could be more along the lines of Google's Site Reliability Engineering practice.
Operating Model: This is the part of the business proposition that articulates how the organisation will be delivering value, generally by articulating the People, Process and Tools used tied together at a high level.  Without an operating model, you have no blueprint for the way the organisation adopt the practices that the culture defines, this, in turn, leads to a lack of clarity and divergent behaviours.
C-Level Aircover: It is often our job as consultants working within transformation programmes to make radical changes to the way business works.  You are going to upset people, and some people won't like the changes - it is important that you have "air cover" from above to change things and move forwards.

Once the high level is in place it is important to find something you can realistically deliver:

Start as small as possible, ideally, once you have some people who understand the culture, a sketch of an operating model and buy-in from the executives create the "Minimum Viable Project", don't attempt to boil the ocean by introducing DevOps to an audience of thousands.  Set an achievable goal:

Automate the creation of the infrastructure from Product X.
Automate the delivery of Product X into Azure across all environments.
Hand-back support from outsourcer Y to a development team in London.
Create a set of tests around our riskiest feature and run them in continuous integration.

Great you have some success under your belt now it is time to start baking this into more teams, add another couple of teams into the mix and get them up and running.  Don't be afraid to offer "White Glove Support" at first to assist them in the transition; they will need a lot of hand-holding over the coming weeks and months.
Now you have several early adopters following a new way of working; you have some critical mass, it is time to start evangelising the work you are doing with a wider audience:

Hold regular show-and-tell sessions ask the early adopters to demonstrate how successful they have been.
Offer drop-in sessions to allow other parts of the organisation to explore how they can come on board with your team.
Enable the creation of Communities of Practice focusing on specific disciplines: Continuous Deployment, Automated Testing, Business Communication, Risk Management, Monitoring and Alerting, etc.

Stay the course and close off the transformation by onboarding the rest of the organisation.  Understand the relationship between the Gartner Hype Cycle and the Adoption Lifecycle.  Prepare for the Transformation Programme to fall into the "Trough of Disillusionment", stay the course and keep the end goal in sight.

For a deeper exploration of the final point read Geoffrey A. Moore's Crossing the Chasm. I could quite literally write a book about how to deliver a DevOps transformation, however by the time I had finished it there would probably be no more DevOps transformation work for me to do.


How to manage the versioning of Azure SQL Databases?

I assume from the ansible tag in your question that you need something that can run from a command line, so that rules out plugins to SSMS like dbForge.

Try Flyway (has a free version) or Red Gate (commercial).


How to run multiple containers with port expose

My problem was that the docker-machine didn't have enough memory to run both services at the same time.

Using those commands fixed it:

docker-machine stop
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" modifyvm default --cpus 2
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" modifyvm default --memory 4096
docker-machine start

(The path to the VBoxManage.exe maybe be different for other users and it can be change to just "VBoxManage" if adding it to the environment paths)


What's the difference between checkin and checkout?

To explain something to anybody, try to compare it to something they are (hopefully) familiar with already.
So that's why I just answer such question like so:

Think of it as arriving at a place to stay (a hotel, a resort, etc):

the very first thing you do (when you arrive) is to checkin.
the very last thing you do (when you leave) is to checkout.

A similar SCM concept applies when you want to apply changes to software components ...  except that it applies the other way around:

the very first thing you do (when you start) is to checkout (or think of it like borrowing it).
the very last thing you do (when you finish) is to checkin (or think of it like giving it back).

Note: this applies to centralized systems (such as the ones used in mainframe environments ...). In systems such as git the "checkout" concept has a completely different meaning (which IMO is also why in those systems there is hardly any confusion about both concepts).


Is it possible to package an application in a .nupkg when creating an application revision in AWS CodeDeploy?

Yes. AWS CodeDeploy bundletype is specified separately from the revision location, so you could upload a .nupkg to Amazon S3, set the bundle type to 'zip', and since a nupkg is simply an archive CodeDeploy will treat it as such and upload it to your EC2 instance.

In your nuspec, make sure your appspec.yml gets placed in the root of your .nupkg. My project contains the appspec.yml and powershell scripts to manage windows services in a directory structure like this:

deploy/appspec.yml
deploy/lib/get.ps1
deploy/lib/start.ps1
deploy/lib/stop.ps1
...

You can include this structure at the root by simply recursively retrieving this directory structure (via double wildcards **) in the nuspec files element:

<files>
  <file src="deploy\**" target="" />
</files>

And then after packing and outputting the nupkg, you can create the application revision as below:


Simple service to check infrastructure status

This is conventionally called a watchdog, deadman, or health check.  Bruce's comment is good, including the part about a raspberry pi.   You could also spin up something simple like monit in a container someplace like GCE or AWS.
Other than setting up an external service or server, there are also a bunch of phone apps that will do the pinging and/or http fetch and HTML parsing for you, right from your phone, providing you with a notification and/or audio alert when a condition isn't met. Since you're a one-man shop, using your own phone isn't substantially worse in terms of being a single point of failure, though you'll want to have a migration plan for when and if you do grow.
The thing I would probably do myself is keep the more complex monit configs on-site, summarize those on a simpler monit config from a stable IP at GCE, with a simple config on my (dynamic IP) phone watching the GCE monit.  That lets firewall rules keep things relatively private other than that summary query from the phone, and when you add a new team member they just need to add that phone app with the one query.  If you're comfortable with leaving the firewall rules more open, then you could skip the GCE step and just have your phone hit a summary statistic on your own server directly.
Back in the depths of time I used to use SMTP mail for this sort of thing a lot; these days I'd prefer the phone app for a more timely notification.


How does one set up OpenStack Swift (object) storage container-specific API keys with Ansible?

After further research, it's evident that it's currently impossible to do this natively.  Therefore, we have to do this in the shell with the command module:

command: openstack container set --property Full-Key={{ KEY }} {{ CONTAINER }}


So first of all, Chef is just a manner of upgrading/configuring, it will help you keep a reproducible state and keeping configuration in line but it won't do black magic and translate your jobs for you.

Now for Jenkins 1 to Jenkins 2, Jenkins-ci site says Jenkins 2 is Backward Compatible.
While this is true, when you update the pipeline plugin, not all plugins are compatible yet. There's a compatibility list on the pipeline plugin github page.

I would recommend installing a fresh Jenkins 2 and porting your jobs from Jenkins 1 to Jenkins 2. This will spot breaking plugins in Jenkins 2, allow you to strip up not needed anymore plugins and refactor your jobs.
This way you can also take advantage of defining the pipelines with a Jenkinsfile along with the code of your application.


Error while trying to run docker redis image on Alpine Linux 3.7.0

One could also use a docker image from an official docker repository like https://hub.docker.com/r/library/redis/

docker run --name some-redis -d redis:alpine


Azure Devops: Filter Test Projects in Nuget Build Pipeline

I noticed that the description for the filepath properties of the pack command is different than the descriptions in the test and publish commands:

Pattern to search for csproj or nuspec files to pack.

You can separate multiple patterns with a semicolon, and you can
make a pattern negative by prefixing it with '-:'. Example:
**/*.csproj;-:**/*.Tests.csproj

So perhaps try -:**/*[Tt]ests.csproj;**/*.csproj instead. I don't think this explains why the unit tests are excluded and the integrated tests are not, though.


Yes, you are right. Azure DevOps (or TFS) Proxy was designed to support Team Foundation Version Control while TFS did not support GIT in earlier versions. The documentation does not contain any information for GIT, it contains only for TFVC: Configure Team Foundation version control.
Consider using Git Virtual File System: https://github.com/microsoft/VFSForGit


How to get Memory Usage from Windows Server 2012 R2 in OpenStack

In PowerShell

Get-WmiObject -Class win32_operatingsystem -Property TotalVisibleMemorySize,FreePhysicalMemory

Or

wmic os get freephysicalmemory

Or

systeminfo


Coding conventions for docker-compose files?

One could use Composerize to create a consistent docker-compose.yml.

There seems to be two options. Options one is to enter some docker run command, e.g. docker run app/test_clients on their website, which will return:

version: '3.3'
services:
    test_clients:
        image: app/test_clients

Or use the command line: composerize docker run app/test_clients.


How to remove directories and files in another layer using Docker?

mkdir dir && cd dir && wget http://google.com && rm -rf dir doesn't do what you think it does.

Let's break it down:

mkdir dir creates dir.
cd dir changes directory into it.
wget http://google.com downloads google.com inside dir/.
rm -rf dir attempts to delete a directory called dir that's in the current directory.

The problem is that there is not dir in the current directory, because you're already cded into it.  And since you've added the -f flag, the command doesn't produce an error.  This is one of the reasons why you shouldn't use force flags without being very sure you need them.

Since you didn't use the WORKDIR command, the directory change is discarded at the end of the RUN.  Thus, the next line executes in the original working directory, where it tries to mkdir dir but, as we've previously discussed, that directory still exists with the wgetted contents inside it.


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.


Ansible: Detecting in parent role when meta dependency role had change

I think you can use listen as explained here: https://medium.com/@george.shuklin/listen-feature-for-handlers-in-ansible-29183524c7e1


When would I use docker-compose's "--service-ports" flag?

According to the Docker documentation:

docker-compose run runs a one-time command against a service. [...]
Commands you use with run start in new containers with configuration defined by that of the service, including volumes, links, and other details. However, there are two important differences.
First, the command passed by run overrides the command defined in the service configuration. [...]
The second difference is that the docker-compose run command does not create any of the ports specified in the service configuration. This prevents port collisions with already-open ports. If you do want the service’s ports to be created and mapped to the host, specify the --service-ports flag:
docker-compose run --service-ports web python manage.py shell
Alternatively, manual port mapping can be specified with the --publish or -p options, just as when using docker run:
docker-compose run --publish 8080:80 -p 2022:22 -p 127.0.0.1:2021:21 web python manage.py shell

This is meant so that you can run singular commands against an already defined service or services using docker-compose run.
For example, lets say you set up a compose file that defines some kind of service. To start the service to run in the background you use docker-compose -f <FILE> up --detach but if you wanted to look inside the container using a terminal, you would run docker-compose run bash.
The reason for the ports being ignored is docker-compose run assumes the container is already set up, and has it's ports set up correctly. If you ran a script that did something involving ports using docker-compose run /path/to/script.sh you might not want it to change the ports that were correctly mapped with your docker-compose up command. This way, the option makes it so you have to tell docker explicitly "I actually want port mappings to change".


The error message you have provided indicates that this is a problem with the configuration that could be permission related.  Here are some steps to help resolve this issue:

You can follow guides where other people have configured the two.  Pay special attention to the permission settings that are selected.
Double check your permissions on the servers.  While you may have configured Jenkins to communicate with Azure DevOps, you still need to make configuration changes in DevOps.
Double/Triple check your URLs on both systems.  I've been burned by dropping an s on http or missing a character on a copy paste.
If you are setting this up within Azure check the Azure Role Based Access Control to make sure proper permissions exist.


Have a look at the Role Strategy Plugin. It allows you to assign roles per project or node, so you can configure detailed permission as required.

There are other CI tools with extended permission-management as well, but I see no need for them: Jenkins is an open source, stable CI system which works well on all important platforms and became a de facto standard. It has many plugins to archive nearly anything. Even rare use-cases can be handled by writing custom plugins/batch scripts.


TL;DR: It is the wrong thing to measure. By measuring and increasing utilization in employees across the board, you create problems in the system and reduce overall throughput.

Throughput Accounting

What you actually want to measure is throughput, inventory and operating expense all together and try to reduce inventory and reduce operating expenses while at the same time maximizing throughput. This method is known as throughput accounting.

In software development, inventory is the work in progress that is not bringing benefits to the customer yet. Anything that has been done, but not released. Throughput is the amount of work useful to the customer that is being released. Any work done that is not directly useful to the customer is accounted as operating expense.

Simple system

In a simple system with single human or multiple humans working independently with independent equipment as much as each one does will directly increase the throughput of the whole system. This leads to the common misconception that is basis for this question that increasing human utilization will lead to increased throughput in all systems. But you still measure the throughput of the system, inventory and operating expenses.

Complex System

In a complex system, even with as little as two dependencies, increased utilization of one part of the system can directly lead to decrease of utilization in the bottleneck, which decreases throughput of the whole system. Any increase in productivity outside of the bottleneck is a mirage.

Example: Team of software engineers has all code reviewed by the software architect, who also makes plans for new features. This person is a bottleneck, code not reviewed by the architect will simply increase inventory, if the architect does not have time, no new features will be properly planed. If you start measuring utilization of software engineers, they will each try to make more changes, rather than better changes. The time the architect will need to spend on each change will increase and the total time spent reviewing will increase further by the increased amount of changes to a point where no time would be left to plan new changes. Eventually the whole system grinds to a halt. If on the other hand they decrease utilization, even spend time idling, they spend longer on each change or peer reviews, this could lead to decrease in time required for reviews and eventually increase in throughput. This is just single team with 2 dependencies. Engineers depend on architect for new changes to be planed and for changes to be reviewed.

Clearly the benefits are to be gained in properly managing the bottleneck and trying to gain productivity at the bottleneck, where hour gained, is hour of throughput of the entire system.

This is the real message of The Phoenix Project and comes directly from the Theory of Constraints by Eliyahu M. Goldratt. You might also read an article on utilization thinking vs throughput thinking. I would also suggest to read more on Critical Chain Process Management.

Remember: What you measure is what you get. And you definitely DO NOT WANT to get increased individual utilization. A road to Hell is paved with good intentions.


Docker compose volume syntax valid for Windows and Linux

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.


Docker won't create a bridge network without being given an explicit subnet

Do you need to run it beside a VPN "OpenVPN service" ?

I think using below would solve the issue for clearing any unused networks by at least 1 container.

$ docker network prune


Managed MySQL cluster - similar solution for a private cloud

There shouldn't be any reason why you can't.  I think that the issue would be in getting the memory management correct on the host.  The orchestration would be the same.

Here's some resources:

https://dev.mysql.com/doc/mysql-cluster-excerpt/8.0/en/faqs-mysql-cluster.html#qandaitem-B-1-13
https://www.digitalocean.com/community/tutorials/how-to-create-a-multi-node-mysql-cluster-on-ubuntu-18-04.  It shows with docker as well. it shouldn't be hard to apply to vmware or k8s.
https://towardsdatascience.com/high-availability-mysql-cluster-with-load-balancing-using-haproxy-and-heartbeat-40a16e134691/
https://www.cockroachlabs.com/docs/stable/orchestrate-a-local-cluster-with-kubernetes.html to set up k8s locally.


What is the difference between Tasksel and CMTs like Ansible/Salt/Puppet/Chef?

From ubuntu documentation:

  Tasksel is a Debian/Ubuntu tool that installs multiple related
  packages as a co-ordinated "task" onto your system.

  This function is similar to that of meta-packages, and, in fact, most
  of the tasks available from tasksel are also available as
  meta-packages from the Ubuntu package managers (such as Synaptic
  Package Manager or KPackageKit).

So in brief, tasksel is just a helper to select and install a bunch of package with one command (acting as a meta-package).

Ansible/Chef/Puppet/Salt are configuration managers, they are able to install packages but that's only a small part of their goal, they aim at converging the system into the state you describe in their respective DSL (Domain specific Language), being package to be installed as well as the content of services configuration files and even up to cloning a git/svn repository somewhere and running install/configuration/database migration tasks for an application.

Building a LEMP stack is just installing nginx, mariadb and php on a linux system, configuring it is another step but that's a common enough task such that there's already existing tutorials about it for every CMT.

Quick list taken from the first page of a google search with 'product nginx mariadb php':

Ansible Tutorial
Chef Official Tutorial (using apache, but moving to nginx is a matter of changing the web server cookbook used)
Puppet tutorial
Salt tutorial


docker | database connection refused between two containers

Your golang api should be included in the compose file and added to the same network.

It also looks like when you run the golang api that you are adding it to a network other than backend, which is the network that is created in your compose file.


Mapping Outbound IPs to 1 IP in Azure App Services

Azure Application Gateway allows you to provide one public IP for those App Services.

You have to make the following steps:

Provision Application Gateway
Add listeners with host name for eachof the App Services
Add backends for each of the App Service
Create HTTP Settings with Override with new host name and Pick host name from backend target options
Add rules to connect listeners corresponding to backends

At the end customer has to white-list one public IP assigned to Application Gateway and create DNS entries to point all App Services addresses to one public IP.

Materials:

Application Gateway support for multi-tenant back ends such as App
service
How an application gateway works


How to add shards to a Redis cluster managed by Terraform without loosing all state?

You can create aws_elasticache_replication_group resource and use data source aws_elasticache_cluster to retrieve an actual amount of nodes. This way you should not write ignore_changes.


How I can retrieve aws lambda cloudwatch logs in txt format so I can search on them?

There are several ways for exporting logs from CloudWatch in searchable text format:
The easiest way of downloading logs in text format is to go to a log group -> Select a log stream -> go to Actions and select Download search results as CSV:

This will download the logs in a .csv format which may or may not be what we want, nevertheless I think it is good for searching a analysis.
A more involved way to export logs would be to select a log group and from the Actions and for that log group select Export Data to S3:

This may export every stream from the log group to an S3 bucket, from which we can download the logs in text format. In order to be able to write to an S3 bucket, we need a policy. There is a full documentation on the AWS docs about how to do this.
I need to mention the CloudWatch provides a way to analyze logs without being able to export them by using CloudWatch Logs Insights. CloudWatch Logs Insights has its own query language.


Which plugin is used to copy file from different environment in jenkins

You are probably looking for something like the Config File Provider. Its plugin page describes it as a plugin which:

  Adds the ability to provide configuration files (i.e., settings.xml for maven, XML, groovy, custom files, etc.) loaded through the Jenkins UI which will be copied to the job's workspace.

If you need something more like a script (as opposed to the configuration file scenario above), you may be interested in the Managed Script plugin. This allows jobs to consume scripts which are centrally stored and defined by the Jenkins admins:

  Managed scripts are shell scripts which are managed centrally by an administrator and can be referenced as a build step within jobs.

If these do not suit your needs, try looking at the Jenkins plugins list


Does anyone have resources, tools, ideas, for automating database create, update, modify, delete

Database migrations are a pretty standard thing for a long time, I believe - not related that much to DevOps, though obviously needed.

There are ready-made tools which are agnostic of your programming environment, i.e., not directly tied to whatever ORM the devs are using.

Strategies of how to actually decide which DDLs/DMLs to feed to the DB might vary; i.e., in the simplest case you just keep track of one global "DB version"; or you have a table which lists individual migrations that have been applied already; or you define a "wanted" state of the DB, and the tool then creates the need DDLs itself to change whatever state the DB is in right now to the new one.

One example of such a standalone tool would be Liquibase (open source), which has a plethora of ways to be configured. I mention that because you say you don't have much time, and it is rather quick to get going - it has one mode where the "configuration" is just a simple file of SQL intermixed with flat (and small) meta information as SQL comments.

The biggest challenge, in my experience is how to handle changing of data structures; one way would be to make all migrations such that they never lose any data, and never break existing code (or data). I.e., you would almost never include a DROP TABLE or ALTER TABLE DROP COLUMN in just any migration, but would let stuff drop out of use, and when a table, or column (or whatever other DB object) finally is not in use anymore, and is inconceivable to be used again, then you drop it. To change, for example, the type of a column, you would create a new one with the correct type, and phase the data over; and so on. This places the work straight on the shoulders of the devs, and not on the migration tool. Which is fine, as this stuff must be in tight correspondence with the DB-centric code of your application, anyways (even if hidden behind an ORM layer).

This is pretty much the same approach as for the software development itself; i.e., creating new features but with a switch (deploying the software with the switch "off", and then being able to toggle quickly), and rolling out parallel implementations of the same feature; only removing the old code when the new one is absolutely proven.


kubelet connecting to docker.sock instead of containerd.sock

In kubeadm docs

--cri-socket stringPath to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket.


docker build fails on one machine but succeeds on another

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.


AWS console is for managing AWS resources, which, arguably, your Raspberry Pi is not.

Some services can work with non-AWS resources. For example you can install System manager agent (though not sure if there is a RPi version) on on-prem servers.

Alternatively you can install AWS Greengrass for Raspberry Pi that gives it some AWS capabilities.

Hope that helps :)


Is GitLab flow (or GitHub flow, etc) anti build-once deploy-everywhere?

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 ;)


How to gain root access to an existing docker container?

Solution is to use exec as:
root@doge:~#
root@doge:~# docker run -ti     -d     --name basexhttp     --publish 1984:1984     --publish 8984:8984     --volume "$(pwd)/basex/data":/srv/basex/data     basex/basexhttp:latest
5699af1dc04aa9c78066222e4b0b8e5621aa2ab9dd2bd46bcd87c6a0377c1960
root@doge:~#
root@doge:~# docker container list
CONTAINER ID        IMAGE                    COMMAND                  CREATED             STATUS              PORTS                                                      NAMES
5699af1dc04a        basex/basexhttp:latest   "/usr/local/bin/mvn-…"   33 seconds ago      Up 30 seconds       0.0.0.0:1984->1984/tcp, 0.0.0.0:8984->8984/tcp, 8985/tcp   basexhttp
root@doge:~#
root@doge:~# docker exec -ti --user root basexhttp bash
bash-4.4#
bash-4.4# whoami
root
bash-4.4#
bash-4.4# su basex
~ $
~ $ whoami
basex
~ $
~ $ exit
bash-4.4# exit
exit
root@doge:~#
root@doge:~# docker container list
CONTAINER ID        IMAGE                    COMMAND                  CREATED              STATUS              PORTS                                                      NAMES
5699af1dc04a        basex/basexhttp:latest   "/usr/local/bin/mvn-…"   About a minute ago   Up About a minute   0.0.0.0:1984->1984/tcp, 0.0.0.0:8984->8984/tcp, 8985/tcp   basexhttp
root@doge:~#
root@doge:~# docker ps -a
CONTAINER ID        IMAGE                    COMMAND                  CREATED              STATUS              PORTS                                                      NAMES
5699af1dc04a        basex/basexhttp:latest   "/usr/local/bin/mvn-…"   About a minute ago   Up About a minute   0.0.0.0:1984->1984/tcp, 0.0.0.0:8984->8984/tcp, 8985/tcp   basexhttp
root@doge:~#


In my opinion there should be a staging branch , which holds the production candidate code.And instead of a Test env , have a staging env which will be complete replica of Prod env. In the Staging env the QA can perform their testing and other checks.

Dev env =  only for developer.
Stage env =  Replica of Prod and holds production candidate build/code , where QA can perform their testing and simulate Prod.

Having a Staging branch has its benefit as you can have code which will merge to master and deploy to prod , and the developer can experiment/work on develop branch without worrying of any accidental merge to master directly.

Once someone completes a feature or fixes a bug/error or implementation is done and testing needs to be performed.

same as above.

Once the code has been passes the test's and QA verified on staging env and No new   feature are to be added to Prod , it can be merged to master.

No new feature are to be added to Prod , QA passed and test cases passed, it can be merged to master

That's where the Staging branch will help , as even if code fails on stage as it is supposed to be complete replica of prod env. we can revert or commit the fix again without worrying of our master branch.


How to avoid a high number of requests for avoiding Amazon AWS EC2 instance AutoScalin?

First of all, the number of connections is not a common metric to use for autoscaling. Much more common is CPU utilization or possibly the amount of network traffic.

If you are happy with the performance of your application at a certain utilization level, you can modify the corresponding alarms configured in the auto-scaling group, so that autoscaling happens only at higher levels of your metric.

Secondly, you can limit auto-scaling to a certain number of instances. When this number is reached, no further scaling will occur.

Finally, if your traffic has a significant proportion of GET requests, it may be easiest to ensure caching headers are set appropriately and traffic is routed through a CloudFront distribution before it reaches the load balancer. This will likely eliminate most of the GET requests from the load balancer altogether.


Securing communication between cloud VMs without private networks. Any strategy besides building own VPN? Spiped?

I am going to suggest an approach that I would not necessarily recommend, because I do not consider it a manageable, scalable solution:

SSH port forwarding.

SSH is a Swiss Army knife in terms of its features. Virtually any port can be securely forwarded to any other port on a remote machine, and indeed through a remote machine to a target machine beyond.  Documentation abounds, but I really like the drawings in this answer. I use ssh across bastion hosts regularly in a manner that mirrors the diagrams at the link.

As I said, I don't think this is a good solution, but it might serve to give you some ideas and it could be one component of a larger solution.

Good luck!


Jenkins - load scripted parameters from a SCM repo

As far as I can tell, there is no native functionality in Active Choice Parameters to load the Active Choice code from SCM.  There are a couple ways to build this functionality yourself, however they're both clunky solutions that can be difficult to debug.  (Unfortunately I can't copy any example code from my work right now because I'm at home on my personal computer.  Remind me after the weekend is over and I might be able to find some example code snippets to go along with these suggestions.)

Your Active Choice scripts can clone a repo, read in a file, and eval it.  This is made quite difficult by the fact that Active Choice scripts don't have any access to the Pipeline DSL, so you can't use any of the steps you would normally use in Pipeline code to clone a repo like scm or git or withCredentials.  There are also many other considerations you'll need to take into account which you normally can ignore in Pipeline code, like ensuring that you run the clone inside a temporary directory and so on.  Ultimately I found this too difficult to do so I have been using the second solution instead:
You can write a separate "meta" job that updates the parameters of your actual job and injects the Active Choice groovy scripts into its parameter configuration. I set this job to run on a hook on the repo which contains my Active Choice scripts, so every time I push to that repo, it updates the Active Choice groovy scripts.  This does rely quite heavily on the Jenkins Java API (which is available in Active Choice groovy scripts), so you'll need to get familiar with the ins and outs of that API.  That API can be quite a maze, especially for Pipeline-related endpoints (since Pipeline source code is heavily modularized and spread out across many repositories and API docs).


Ansible: When 'directory/file exists' in a loop

You should first stat for the password file, and then set the fact depending on whether the file.stat.exists or not. And both those tasks need to be performed for each user.

As of Ansible 2.4 you can dynamically include_tasks and perform a loop on it. Meaning that you can group a few tasks in a file and loop those tasks for every value in your loop-variable.

I think this should be able to solve your problem by creating a separate tasks file containing these tasks that should be run for each user:

Stat for the password-file:

   - name: Check if password-file exists for user
     stat:
        path: "credentials/{{ item.username }}/password.txt"
     register: password_file

Next you can define your tmp_user var when the password.txt-file exists:

   - name: Set fact for user
     set_fact:
       tmp_user:
        - username: "{{ item.username }}"
          first_name: "{{ item.first_name }}"
          last_name: "{{ item.last_name }}"
          email: "{{ item.email }}"
          password: "{{ lookup('password', 'credentials/' + item.username + '/password.txt length=15 chars=ascii_letters') }}"
          roles: "{{ item.roles }}"
      when: password_file.stat.exists
      register: set_tmp_user

Then, if previous task defined a new fact tmp_user, that fact should be added to the tmp_users list.

   - name: Add user to list
     set_fact:
       tmp_users: {{ tmp_users + [ tmp_user ] }}
     when: not set_tmp_user is skipped

(not sure by head if you can use when: set_tmp_user is changed but not is skipped should do the job)

Then in you main tasks-file, you create an empty tmp_users list and call an include_tasks in a loop to loop through the above tasks:

   - name: Include users.yaml and setup all vars for nexus
     include_vars:
       file: users.yaml
       name: users

   - name: Initialize tmp_users
     set_fact:
        tmp_users: []

   - name: Set user facts
     include_tasks: set_user_facts.yml
     loop: "{{ users.nexus_local_users }}"

Disclaimer: I have not been able to test this out, or check its syntax, but I assume the general idea of which I try to accomplish here should be clear?

Also be aware that you currently can't perform a loop inside the included tasks file as that loop will by default overwrite the item-variable defined by the tasks-loop. See defining inner and outer variable names with loop var to solve this.

And an additional tip: add a debug task as first task to your included tasks file to output the current item.username in the loop.


For storing avatars in s3, which approach has the lowest cost?

For the best performance naming many small files in an s3 bucket may not be the best idea unless they user_id is a random string. See how the S3 hashing algorithm works https://aws.amazon.com/blogs/aws/amazon-s3-performance-tips-tricks-seattle-hiring-event/

So replacing it by a random hashed value may not be that bad. Of course you need to store the hash in the user profile or you need to calculate it from something. If you add something like profile id or last changed timestamp you can do sha1/md5 of (userid+lastchanged) and if you update timestamp you has the hash of the current avatar.

The older one you can simply delete. CloudFront will remove it from its cache after expiration https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html

This will more complex algorithm, but if the costs are the concern, a little bit of extra work seems to be a reasonable approach. Not sure how do you handle the uploads, but it may be a good opportunity to play a bit with step functions which would make sure that the new avatar is uploaded correctly and then the old one is removed as well.

It's kind of a programming question, but I get your point - it is very specific to AWS environment and requires a particular knowledge about how the infrastructure works.


Robuster and more practical solution is an encrypted file. For example

shell> cat vault1.yml
my_email: admin@example.com
my_tag: tag123

shell> ansible-vault encrypt vault1.yml
Encryption successful

shell> cat vault1.yml
$ANSIBLE_VAULT;1.1;AES256
33376431383930313965356364356136306338383238303032363165633962636366663939373237
3433383262306631643431346236653534316331643466660a326562663633346662656233353733
63373561636432653535666437656537326635363935366261666237353136313939323535336665
3333666466656664610a633430313138393238653065623231393165383162656262646139353730
63653231363465643237666465613631646539366262656537323932346530386364353132326234
3230623232393630396361333462343862323231323733376665

Then the encryped file can be used in various places. For example

shell> cat playbook.yml
- hosts: localhost
  tasks:
    - include_vars: vault1.yml
    - debug:
        msg: "email: {{ my_email }} tag: {{ my_tag }}"

gives

    "msg": "email: admin@example.com tag: tag123"

Including vault-encrypted variables in a task

It's possible to limit the scope of the variables to a task. This limits the exposure of the sensitive variables and makes the solution safer. For example

    - debug:
        msg: "email: {{ my_vault.my_email }} tag: {{ my_vault.my_tag }}"
      vars:
        my_vault: "{{ lookup('file', 'vault1.yml')|from_yaml }}"

gives the same result.


Get Ansible to print lines for include_role(s)

I was able to create a custom callback plugin. I started with the default callback code and modified it:

    def v2_playbook_on_task_start(self, task, is_conditional):

        if(task._role is not None and task._role != self._current_role):
            self._current_role = task._role
            self._display.banner("ROLE [" + self._current_role.get_name() + "]", color=C.COLOR_DEBUG)

        self._task_start(task, prefix='TASK')

Now the output looks like:

ROLE [some_role] *****************************************************

TASK [some_role : I'm a task!] ***************************************
ok: [MACHINE]

TASK [some_role : Some other task!] **********************************
ok: [MACHINE]

ROLE [another_role] **************************************************

TASK [some_role : I'm a task!] ***************************************
ok: [MACHINE]

With the role line being bolded. It's a work in progress, but it at least makes it a lot more obvious where roles are being executed. My determination on block is that it is impossible to do what I wanted, due to the way the block class is implemented in Ansible.


Why does `docker-login` fail in BitBucket pipelines?

At the moment the docker login and docker push commands are only available to Pipelines Alpha members.

You can read about the features available to Alpha at "Pipelines Alpha".

In order to participate, the above link includes instructions on how you can opt-in to the added functionality.

Personally I received an e-mail from Atlassian a day after signing up saying my projects now include Alpha features. So this feature works in my pipelines without any issues.


There is a systemd shutdown task (/etc/systemd/system/k3s.service) which stops the server, but not the k8s resources (pods, networks, etc). For this there is a utility script k3s-killall.sh which should be at /usr/local/bin/k3s-killall.sh


How to execute a Jenkins job until the build is green

This pipeline will run each day at 1 AM. It'll restart if the build fails.

pipeline {
    agent any

    triggers {
        cron('0 1 * * *')
    }

    stages {
        stage ('Build') {
            when {
                expression {
                    // When last build has failed
                    !hudson.model.Result.SUCCESS.equals(currentBuild.rawBuild.getPreviousBuild()?.getResult()) == true
                }
            }

            steps {
                sh "./myjob.sh"
            }

            post {
                failure {
                    // If the current job has failed, trigger it without
                    // waiting.
                    build job: "${JOB_NAME}", wait: false
                }
            }
        }
    }
}

If you want to wait before to re-trigger the job, you can add the option quietPeriod: (seconds) to the build step (https://jenkins.io/doc/pipeline/steps/pipeline-build-step/).

You might have to add these methods to the scriptApproval:


micrometer exposing actuator metrics vs kube-state-metrics vs metrics-server to set pod request/limits

Based on what I see so far, I have found the root cause, renamed kubelet service from old chart to new that can get targeted by serviceMonitors. So for me the best solution would be grafana kube-state-metrics + comparing what I see in the jvm dashboard


Methodology for software development and deploy in fast-paced agency

In terms of development procedure, you should consider using the agile method. This is the most widely used method of software development and has proven itself. Within the scope of the agile method Pair programming will allow you to spool up another developer to assist with your projects when you are ready and find that you have more work than you can handle. You can then move into a standard agile method like scrum/kanban/scrumban (or continue the pair programming if you find you like it!)

One particular reason for choosing this method is that is lends itself well to DevOps and Continuous Integration. In fact, one could describe DevOps as a specific way of implementing the agile method. The Iterative, incremental and evolutionary philosophy of agile and the very short feedback loop and adaptation cycle marry beautifully with DevOps/Continuous Integration and provide a solid foundation to build upon.

  Here in the agency we have a infrastructure team as well, with the possibility to set-up our own internal or external servers to handle things.

Make good friends with the infrastructure team. Involve them early and often and drive them towards a Infrastructure/Configuration as Code philosophy which will allow you to collaborate closely with them. While it might seem like it is faster to just do it manually, doing so is creating technical debt. In a few years when it comes time to upgrade, no one will remember how the thing is built. It will also allow the infrastructure team to look good. Never again will they make a mistake or forget a step during deployment. Either the deployment code works or it doesn't and it will deploy exactly the same way it deployed in test/staging - making deployments and upgrades easy and horizontal scaling a breeze. Ignoring these techniques also slows down your development. If you can just fire up a new server, have it pull down (and compile) your latest git commit, run through an automated testing suite and then E-mail you the results while you go do something else it is a huge time-saver.

If you can, utilize the cloud - with Amazon for instance, a lot of the tools are already built for you. While this might make your Infrastructure team leery, just remind them that the cloud is just someone elses computer. All the cloud does is provide you with hardware. It will still require someone from the infrastructure team to install maintain and operate it. And it will allow you to avoid scalability issues. The database problems, storage and backup issues and headaches have now been outsourced.

  and I have little control over the client's servers.

See what you can do about this. Consider leveraging a tool like The Forman's Katello scenario (I like to deploy it with Salt Stack personally - I don't like ruby) which will allow you to manage and deploy your VMs on nearly any iron or cloud (including bare metal), manage the configuration of that hosts using Salt Stack, Chef, Puppet or Ansible, manage your docker containers and manage updates to your machines. This will allow you to then easily provide the code to your client to either A) automate or B) manually deploy their updates and deployments. Once you have proven the value of the speed and efficiency this method gives you, you may be able to simply use these same tools to spawn your client a copy of this stack for managing their environment or you may be able to talk/upsell your clients into letting you manage these deployments - The Foreman will allow you to configure sites and organizations (as well as mange users if paired with FreeIPA) so you can configure multi-tenancy. And the project is backed and supported by Red Hat.

If you have any doubts about the above, I recommend you pick up a copy of "The Phoenix Project" of the Audiobook which illustrates very well the value and benefit of the above.

  One of the first things I plan to do, is to elect a preferred development language and framework

If you go this route, just make sure to standardize on a language that plays well with REST most DevOps stuff uses this interface.

And finally,

  The entire dev team had been hired by another company - and they didn't have a solid process as well, only a few gits here and there

Do what you can to merge these together into one place. It will make your life a heck of a lot easier.


Monitor program progress on multiple servers

Any time you're running ad-hoc long-running commands, you should step back and rethink your process, because that should be automated, including error handling.

Rather than connecting in to the servers to see status, a better approach is to push that information out. You can do a wide variety of things if your want to write a bunch of custom code, but the simplest thing is probably to start sending the output through syslog to a centralized logging system (syslog itself, or ELK, or whatever). That way you can monitor everything from a central location.

Thinking forward, if this isn't a one-off task, monitoring should be automated. That is, you should never have to just watch logs to see if things are progressing as they're supposed to. Instead, you should assume they are (and continue with other work) until your alerting fires off. This is an investment of time into getting reliable and wide-coverage alerting, but as your systems grow in complexity, it will pay off as you don't have to monitor everything any time you change anything.


Is this what you're looking for?

- hosts: all
  vars:
    bunch_of_specific_packages:
      - apache2
      - gcc
      - gedit
  tasks:
    - package:
        name: "{{ item }}"
      loop: "{{ bunch_of_specific_packages }}"


How to manage Docker images and their child images in a pipeline?

There is a good practice called multistage build, in which you have one Dockerfile containing various image definitions that depend from one another, this helps you keep all your images updated with the latest changes and copy artifacts from one to another; this also helps reducing the image size if done right.
A simple example is like the following:

FROM golang:1.9.2 as builder
ENV CGO_ENABLED=0 GOOS=linux
RUN go build -a \
             -installsuffix cgo \
             -o app .

FROM alpine:3.6
WORKDIR /root/
COPY --from=builder app .
CMD ["./app"]

In this example, in the first image you compile a go example application using the golang official image and then, using alpine to keep the size of the image small, you copy the executable to a new image and execute it.
This way you can keep your containers in one file and build all at the same time or you can build just a target stage:

docker build --target builder -t somehub/sometag:latest .

You can even use remote images as stages:

COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf

If you need anymore information regarding Docker multi-stage builds you can find it in the following link.


How do I enable Progress report for Test Plans

According https://docs.microsoft.com/en-us/azure/devops/test/track-test-status?view=azure-devops it should be available by clicking on Progress report under Test Plans.


How do I get the find module to work in Ansible?

Remove use_regex: yes. Quoting from the doc

  If false the patterns are file globs (shell) if true they are python regexes.

If you want to use Python regex then the pattern would be probably something like this

patterns: '[j]{2}.[j]{2}'

You probably want to append to file >>

echo {{ item.path }} >> /tmp/results.txt


There is currently an issue open to share Gradle cache between containers:

https://github.com/gradle/gradle/issues/851

I think the best solution at the moment is to bake as many dependencies in to the Docker image as possible, and then use a volume to share between sequential builds, limiting it to one concurrent build per host. You can mount the cache on to the host with a docker-compose.yml like so:

version: '3'
services:
  gradle:
    image: gradle:4.0.1-jdk8-alpine  # I'd suggest using this as a base to build your own Gradle image with dependencies baked in
    working_dir: /usr/src/app
    volumes:
      - ./:/usr/src/app:Z
      - ./.gradle:/home/gradle/.gradle:Z

Alternatively, another solution would be to look at network-level caching e.g. Squid.


Diagnosing large delay in file sync to Docker for Mac

I figured this out, and it was related to the opcache settings for PHP in my docker image. The opcache re-validate frequency was set to 60 seconds, meaning that PHP caches files in memory for that long before referring to the filesystem again. Changing this to 2 seconds resolve the issue, but adds a significant performance penalty :(.

See more info: https://drupal.stackexchange.com/questions/253111/delay-in-code-changes-on-custom-pages-in-drupal-8-in-a-docker-environment


Is cross-region replication 100% fool-proof for S3 region outages?

The drawback when there's replication come from the note below:

  Amazon S3 routes any virtual hosted–style requests to the US East
  (N. Virginia) region by default if you use the US East (N. Virginia)
  endpoint (s3.amazonaws.com), instead of the region-specific endpoint
  (for example, s3-eu-west-1.amazonaws.com).

When you use replication you usualy let AWS takes care of routing the alias to one region by targetting s3.amazonaws.com in your REST request from your servers and let the redirect do it's job.

Whenever N.Virginia is down, the magic cease to work and you're out of luck to access your data and have to update your configuration to choose a specific region endpoint.

The problem does not come from the DNS (a request to the bucket itself will work) but from S3 clients, which will connect to the S3 API endpoint before accessing the bucket, in this case the dns resolution is done on s3.amazonaws.com and this is us-east-1 endpoint.

When you use regions alias, you loose the ease of load balancing over regions with the health check from AWS included.

If you use DNS cname targeting the regions to switch quickly, you're responsible of your DNS TTL but nothing guarantee cache servers of client ISP will honor your value (one of many cache your client may encounter).

And lastly, if you try to load balance yourself you'll probably create the same SPOF than AWS already have with the added burden of maintaining it.

AWS is working on it but that's all the information I have at time of writing.


Consul cluster does not work as expected when one of server is down

Based on my understanding of the topology you have described you essential have:

3 Nodes - 2 Servers and 1 Client

This layout is immediately a problem because the clustering protocol that consul uses relys on being able to easily elect a leader, which requires an odd number of servers.

If you consider the failure scenario of a 2 node consul cluster - as soon as a single node goes down your one remaining node cannot achieve consensus by itself because there's no way to get a majority of the servers voting on something.

In the consul docs the consensus protocol is reasonably well described Consensus docs

They even include a summary table which explicitly states how many server members could be lost for varying cluster sizes.

Following their advice, your 2 server cluster cannot withstand any fault because it would then become impossible to achieve quorum.

Really a minimum number of servers for a functional consul cluster is 3.


Exemplify CI/CD to a colleague from Microsoft world using product-neutral terms

I would say that instead of describing a CI/CD system by the products/tools that you use, you should be describing the system by the purpose of each step in the system. Instead of saying "I have a Jenkins server that builds the artifacts, stores them in Artifactory, then Puppet deploys the artifacts to EC2." You could say, "Our build server creates and stores our artifacts in an artifact repository. Then our configuration management software detects the artifacts and deploys them to our cloud infrastructure." Your colleague can then make the connections and find the correct solution that Microsoft provides.


Should I build my own pipeline or use GitLab for Kubernetes?

One could just run kubectl apply -f <file>. When one updates an application, one could just run this command. A CI is basically able to run scripts. As GitLab is just a CI and a Git repository one could just run kubectl in a gitlab-ci.yml pipeline.


Unverified as it sounds brittle to me to start a container outside of k8s supervision, but you should be able to mount /var/run/docker.sock with a hostPath volume.

Example variation from the documentation:

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /var/run/docker.sock
      name: docker-sock-volume
  volumes:
  - name: docker-sock-volume
    hostPath:
      # location on host
      path: /var/run/docker.sock
      # this field is optional
      type: File

I think a simple mount should be enough to allow communication from docker client within the container to docker daemon on host but in case you get a write permission error it means you need to run your container as privileged container
 using a securityContext object like such (just an extract from above to show the addition, values taken from the documentation):

spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    securityContext:
      privileged: true
    name: test-container


Is there a way to disable a Jenkins plugin for a single job?

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.


Are CI and CD DevOps team tasks or are these separate professions?

DevOps is a combination of two roles Development and Operations, CI & CD are the main role a DevOps must be doing. Continuous Integration (CI) is a part of developer's role and Continuous Deployment/Delivery is a part of operation/infra/release-management role. In the agile methodology of development we've combined these two different role to a new position called DevOps who'll be responsible for release management or deployment. Thus it is a mandatory for a DevOps to know about CI & CD.


Sarbanes-Oxley (SOX) Versioning Strategy

I suggest to follow the principles that are defined in the Semantic Versioning 2.0.0 documentation.


Per the Jenkins documentation:

  Cleanup per project/job is performed after that job runs.

  As of v2.221, cleanup will also periodically run using the new Global Build Discarders (even if a job has not recently been run).

Source.


How/where are programs installed in Docker containers?

Hi and welcome to DevOps SE and Docker!

Now the concept of Docker is to create isolated virtual  environments, actually it's just a process or more but wrapped in its own environment.

So at first hand you could take any Docker image and the scripts inside would be there where the creators of the image placed them.

If you decide to create your own Docker images, and I believe you will sooner or later, then it is up to you how layout the system.

Additionally, you could link - proper term is here mount - your system's folders with those of the container but still the execution will take place inside the container.

For example to install the RStudio package in an Anaconda3 environment, I have tried the following.

$ docker run -it continuumio/anaconda3 bash
(base) root@7162c3acc9e3:/# conda install -y -c r rstudio
(base) root@7162c3acc9e3:/# which rstudio
(base) root@7162c3acc9e3:/# /opt/conda/bin/rstudio

As you can see, if installed as root user which is default, the path is /opt/conda/bin/rstudio. Most packages not using special system capabilities would considerably not "know" whether they are in a Docker environment or not, so in many cases you could consider a Docker container to be just a (fluid) environment you have the root access too.

Additional note on the terms:

image is a blueprint for a container defined by a Dockerfile. "Installing" something in an image means you add instructions to its Dockerfile. Own images can be derived from others by the statment FROM.
container is basically process isolation in its own OS environment. If you install something in the container during its uptime, this change will be gone with the container.


Fastlane Screenshots with Authentication

Please check in Fastlane docs Launch Arguments under Advanced Snapshot section https://docs.fastlane.tools/getting-started/ios/screenshots/ I think it can help

  Launch Arguments

  You can provide additional arguments to your app on launch. These
  strings will be available in your app (eg. not in the testing target)
  through NSProcessInfo.processInfo().arguments. Alternatively, use
  user-default syntax (-key value) and they will be available as
  key-value pairs in NSUserDefaults.standardUserDefaults().

launch_arguments([
  "-firstName Felix -lastName Krause"
])

name.text = NSUserDefaults.standardUserDefaults().stringForKey("firstName")
// name.text = "Felix"

  snapshot includes -FASTLANE_SNAPSHOT YES, which will set a temporary user default for the key FASTLANE_SNAPSHOT, you may use
  this to detect when the app is run by snapshot.

if NSUserDefaults.standardUserDefaults().boolForKey("FASTLANE_SNAPSHOT")

  {
          // runtime check that we are in snapshot mode
      }

  Specify multiple argument strings and snapshot will generate
  screenshots for each combination of arguments, devices, and languages.
  This is useful for comparing the same screenshots with different
  feature flags, dynamic text sizes, and different data sets.

# Snapfile for A/B Test Comparison
launch_arguments([
  "-secretFeatureEnabled YES",
  "-secretFeatureEnabled NO"
])


Preinstall packages for a nodejs Docker Image according to package.json

Depend of life cycle of you app, because Node libraries and dependences change or end life to obsolet, so if you app constant change version to deploy, you can use docker tag for describe version or time when it build image, is a good practice, so Dockerfile shall copy package.json, and too look when you need change image source OS, by example change ubuntu linux to alpine , many dependences or how to install "npm" and dependences for node, a example:

  FROM alpine:3.8

# Update
RUN apk add --update nodejs nodejs-npm

# Install app dependencies
COPY package.json /src/package.json

RUN cd /src; npm install

# Bundle app source
COPY . /src

EXPOSE 5000
CMD ["node","src/index.js"]

well , hope it help you


REST API: create project with powershell returns unspecified internal error

Your script works, just update the last content type to application/json:
Invoke-RestMethod -Uri $adoTaskUri -ContentType "application/json" -Body $body -headers $adoHeader -Method POST

PATCH is used to update a team project: https://docs.microsoft.com/en-us/rest/api/azure/devops/core/projects/update?view=azure-devops-rest-6.1


Chef vs Ansible: will configuration be applied if connection is lost during configuration pulling/pushing?

The safest assumption to make here is that the configuration is not applied completely and you should try again once the network is back.  You can set things up to work without the network, but why go to that work when it will try again for you in a few minutes?

Chef

Chef tends to be run in the client-server mode as you describe so the chef-client agent on the "controlled" machine would keep running.  It would get stuck when it needed to get cookbooks or figure out which roles were assigned.  It will eventually time out and the chef run will fail.  Then it would try again in a few minutes.  By default the agent tries to do a chef run every 30 minutes.

If you're using chef-zero instead of the client-server style of chef then you could have everything staged on the "controlled" machine so that any network interruption wouldn't break it because of chef itself.  You might still have network dependancies in the cookbooks used.

Ansible ssh // push

Ansible started off by doing everything via ssh.  In this style of Ansible the completion state on the "controlled" node would be unknown but from the perspective of the user running ansible that node would clearly need to be retried.  Ansible creates a file for you with all of the hosts that need to be retried.

Ansible in cron // pull

If you're running Ansible from a cron job then it will face similar issues to the classic chef-client.  The node will need to phone home to find roles and updates, but it will time out and retry later.


Git Release branching strategy for Continuous integration and deployment

You need to separate the 2 concepts a bit:

the integration part - how are the changes integrated into your master branch (or some other integration branch, that's also possible), which may be continuous or not. Technically neither approach you describe is actually continuous integration unless your feature branches have a very short lifespan - typically less than 1 day. But this part doesn't seem to be the main focus of your post.
the delivery/deployment part - how are the integrated changes from an integration branch (master in your case) being delivered/deployed. In other words your release branch strategy. This appears to be the point of your post, I'll focus on it below.

Both approaches you describe are valid release branch strategies, I've seen both being used. Each with their own advantages and disadvantages.

This approach is inline with the continuous delivery/deployment strategy. The CI/CD pipeline will have the commits to the master branch (either feature branch merges or point fixes) as entry point: each such commit will trigger the pipeline verification, attempting to progress into it as far as possible. The QA/UAT is one of your pipeline steps, it that passes then it goes into production. Effectively your releases are simply selected (typically tagged) commits from the master branch, they aren't really branches.

Advantages:

as you noticed - the least amount of branch activities
everyone is on the same page - developers, QA, etc all focus on the same branch context
lowest cost (but only if the project scale allows it to be effective, see also the disadvantages section)

Disadvantages:

you can't have actively maintained releases - you only have one "current" release out there, each additional fix will become another release. Which isn't necessarily a bad thing, such release model can actually be desired (for example in the case of SaaS products).
the release cadence is not actually predictable. It may be difficult to get releases out - if a problem is detected, by the time the fix for it is merged into the master branch some other changes may be merged in and other problems detected. This gets progressively worse as the rate of branch commits goes higher (larger scale projects) and may actually be non-convergent (the project may not reach stability at all). Doing CI/CD at scale is not a trivial matter.

This approach is a more traditional release strategy, but technically it's not really continuous delivery/deployment.

Advantages:

more predictable release cadence. The spinned-off release (aka throttle) branches allow reducing the rate of commits for a particular release. Typically a release branch would only receive fixes necessary for that particular release, fixes for future releases (or release trains) would go into the master branch instead. The reduced commit rate allows reducing the risks of new problems being introduced that would require additional commits, the branch is more stable. Typically the release branches are pulled from the master/integration branch commits that passed all (or most) of the CI/CD pipeline verification stages (for the master branch). In your particular example those branches wouldn't expect subsequent commits (they passed QA/UAT), but if say a problem is detected after deployment in production it would be possible to just commit that particular hotfix into the branch and re-deploy, without having to pick up any other commit that went into master since the branch was pulled, reducing the risk of additional regressions.
it supports multiple simultaneous/overlapping actively maintained releases, with potentially complex release policies in place (long-term/short term/rolling/etc, like OpenSUSE's Lifetime for example).
it supports multi-level releases (like major.minor.increment, for example) - aka release "trains": a major release branch could itself have multiple minor release children branches, etc.
each release branch could actually use the CI/CD methodology at its own level, independently of the other release branches - if it never gets upstream/bulk merges from its parent (i.e. effectively becoming its own "master")!

Disadvantages:

everyone is no longer on the same page. Each release branch has its own context which may come with its own policies, processes, tools, necessary resources, etc. Each requires its own development/testing/validation. This drives development/maintenance costs up, often significantly.
tracking issues and propagating fixes across multiple releases may not be trivial. Merging back release branches into master (or their parent branches) appears an inviting approach, but IMHO it's a bad practice, see How to get rid of develop branch for simplified Git flow .
context switching becomes a major problem.


AWS Cloudformation: Callback only for CREATE_COMPLETE or CREATE_FAILED of entire stack

I believe, alternatively, you could use CloudTrail+CloudWatch rules, but then you will get CREATE_STACK events for all stacks
Here is some information about that:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-api-logging-cloudtrail.html
https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html

And, of course, there's the option to put a lambda which listens on the notification topic and filters the needed events before sending the email.


Securely grab minion ID in pillar top file template?

There is currently one safe way to do this.

You can use {{opts.id}} as an explicit way to grab the minion ID. opts is technically an implementation detail; the opts dictionary is a Salt internal structure that doesn't appear to be formally specified. Its candidacy for the purpose was pointed out to me in a bug comment.

In the next version of Salt (so, later than 2016.11.5) the id grain, will have been special-cased, making it possible to use {{grains.id}} safely.


Build FreeBSD Docker image using Ubuntu host OS

As you can't build a docker image for an arm kernel from a x86 one neither.

Nor can't you build an image with a glibc lib targetting a 4.x kernel on a host running a 3.X kernel.

Docker isolate processes and give a virtual filesystem but that's still the host kernel who own the process, so obviously without a layer of hardware virtualization like virtualbox, vmware, xen, kvm, there's no chance to build an image with binaries made for a different kernel type.


What is the difference between a jail environment in linux and docker container?

While both Docker and jails have some similar functionality, they are built for different purposes.

The term "jail" comes from the FreeBSD distro.  A lot of people will also refer to a chroot as a jail.  At its core these jails virtually change the root directory for a process and its children.  This means that these processes are contained (jailed) within this new directory and should not have access to folder outside of it.  Jails are a great way to run a process that you want isolated from the rest of the system.

Docker Linux is an entire platform for running containers.  At its core it does this by using Linux namespaces and Linux Control Groups (source).  Docker is built around packaging these containers and allowing them to easily be shared with other systems.

Ultimately, both technologies are isolating processes.  However, Docker does this with the intent of making the isolated processes portable and repeatable.


Jenkins 2.164.3 - programmable plugins installations for specific versions

Why not use Plugin installation manager tool?

Your alternative would be the install-plugins.sh referenced in the tool readme.md. You can explicitly list all plugins and versions or let it auto-resolve dependencies.

See also answer in S/O re:Jenkins plugins for old versions.


why can't map local path to docker's inside?

Oh! I have search for a while, it's should be like:

docker run -d --name=ak_registry  --restart=always -p 7900:5000   -v /data/.docker:/var/lib/registry    registry

Used /var/lib/registry instead of /tmp/registry


Does Jenkins support cloning git submodules with "git@" (not "https") URLs?

As a reference, it works for our system, submodules over SSH. We use deploy keys for this purpose. In Gitlab they can be found under Settings --> Repository --> Deploy Keys. The used key has to be marked as Enable in each used Git repository (main and submodules).


I would love to get some clarity too maybe from a more authoritative source than myself (I'm sure I'm guilty of FUD too).

I've been looking to deploy to Azure using Kubernetes.  I am similarly confused but I think that is because there isn't one clear path.  I can't speak for Microsoft but their attitude to cloud seems to be they are happy to become "all things to all men".  If you are using Azure, Microsoft don't seem to have a strong opinion on how you get there.

Microsoft are actively trying to evolve; e.g.
Linux now dominates Azure

Clearly Azure DevOps deployment pipeline does exactly what Jenkins can do - so in that sense it is a competitor.  There is also that slightly off-putting upfront Azure DevOps pricing for parallel pipelines.

On the one hand, Azure DevOps appears to be a re-branding of Visual Studio Team Services.  So it will be familiar to people already within the traditional Microsoft development ecosystem.  At the same time Microsoft are making great efforts to embrace technologies that are not traditionally Microsoft (Go, Java, Node.js, Python, Ruby, PHP etc).

It is early days - but it is not a surprise that Azure DevOps pipelines should prefer the Microsoft Git properties of Azure Repos and GitHub.  In the same way that BitBucket pipelines prefers BitBucket and GitLab pipelines prefer GitLab.

Meanwhile;

The Azure Marketplace offers a Jenkins deployment that comes with Azure deployment plugins out of the box.

Many Jenkins plugins have been developed by the Azure DevOps team.

in addition;

Microsoft have put their backing behind Kubernetes related projects Helm and Draft.  Helm is a package manager for Kubernetes.  You can even use Helm to deploy a Jenkins installation into Kubernetes.

--

It would be interesting to see someone weigh up the benefits, costs and effort of running your own Jenkins in Azure verses using Azure DevOps pipelines.

... and then there is Jenkins-X.

So it would seem we have many options and decisions to make.


jenkins parameter behaves differently from internally defined variable

It seems that the jenkinsParam is holding the output after escaping the special characters.
You are assuming that jenkinsParam = "test\ntest" and however it looks like it stores it as jenkinsParam = "test\\ntest"

See how it behaves if I use echo it these two different cases:

(I have tested this in groovy shell)

1st Case:

jenkinsParam = "test\ntest"
print jenkinsParam
test
test

** 2nd Case:**

jenkinsParam = "test\\ntest"
print jenkinsParam
test\ntest

In order to replace the payload which is stored in the jenkinsParam (2nd case behaviour), you need to replace the complete \\n from the string. Check the example below:

output = jenkinsParam.replaceAll('\\\\n', 'yes')
print output
testyestest


The easiest way is not to handle this information)) You will get tired of such useless information like containers restarts.

Anyway, there is couple of tools to monitor docker with prometheus:

Google cadvisor
Docker experimental prometheus metrics

But it requires installation of prometheus, alert-manager, find metrics for triggering and set up alert rules.

Or maybe try to find zabbix tool for monitoring docker containers.


Circle ci workflow job stuck in "created" when adding a required step to the workflow

Due to the fact that build had a branch filter... Even though no error message on additional info is shown...

Hence I needed to add the branch like so:

workflows:
  version: 2
  build_deploy_test:
    jobs:
      - build:
          filters:
            branches:
              only:
                - develop
                - devops-docker-intial
      - christest:
          requires:
            - install
          filters:
            branches:
              only: devops-docker-intial


Overcommiting CPU Resources in Kubernetes

You should be able to use the flag spec.containers[].resources.limits.cpu to set your desired state on a deployment.

The official docs here and here have some examples of how to specify this in the yaml.  You can set a global default along with min/max limits:

spec:
  limits:
  - default:
      cpu: 1000m
    defaultRequest:
      cpu: 300m
  - min:
      cpu: 300m
  - max:
      cpu: 1000m


Terraform fails to modify DNS settings a recently created VPC Peering connection because it is not yet active

Figured it out!
The problem is that those DNS settings set in aws_vpc_peering_connection_options cannot be set until the peering connection is active (approved). It was only depending on aws_vpc_peering_connection existing, therefore was running at the same time or before aws_vpc_peering_connection_accepter.

This was simply fixed in aws_vpc_peering_connection_options by getting the vpc_peering_connection_id from aws_vpc_peering_connection_accepter instead of aws_vpc_peering_connection, so that the terraform dependency tree would automatically have the dependency work in the correct order.

Before:

resource "aws_vpc_peering_connection_options" "sb_vpc_peering_options" {
  vpc_peering_connection_id = aws_vpc_peering_connection.sb_vpc_peering.id

  accepter {
    allow_remote_vpc_dns_resolution = var.accepter_dns_resolution
  }

  requester {
    allow_remote_vpc_dns_resolution = var.requester_dns_resolution
  }
}

After:

resource "aws_vpc_peering_connection_options" "sb_vpc_peering_options" {
  vpc_peering_connection_id = aws_vpc_peering_connection_accepter.sb_vpc_peering_accepter.id

  accepter {
    allow_remote_vpc_dns_resolution = var.accepter_dns_resolution
  }

  requester {
    allow_remote_vpc_dns_resolution = var.requester_dns_resolution
  }
}


Is it possible to locate the temp keypair generated by Packer?

First, make sure that packer runs in debug mode (packer build -debug ...), otherwise the temporary key will not be written to disk but will only be kept in memory.

packer will store the key in its working directory. In other words, look in the same directory from which you started the packer process.

If you use AWS, the file will be called ec2_amazon-ebs.pem. Assuming you are building an Ubuntu image, you should be able to login to the instance with this command:

ssh -i ec2_amazon-ebs.pem ubuntu@<ip>

(where <ip> can be found in the packer output or through the AWS console)


Is it ok to logout after calling docker stack deploy?

It is safe. As soon as docker returns it is safe to logout/leave the shell.

The issue was that Docker 18.06.0-ce broke docker stack deploy. Reverting to 18.03.1 (specifically 18.03.1~ce-0~ubuntu) made it work.