Does a DB connection prevent AWS Aurora Serverless from pausing its compute capacity? I want to host an application that connects to a DB and makes queries to it. The application holds onto the connection indefinitely but only makes queries to the DB when the user interacts with the frontend.
I know that AWS Aurora Serverless has a "pause compute capacity" feature to only charge you for the DB's storage after a specified amount of time. If the application is still connected to the DB (even without making queries), does that prevent the DB from scaling down to 0 compute units and pausing its compute capacity?

I believe you are correct, a single long-running connection will prevent AWS Aurora Serverless from triggering the pause-and-resume feature.

Aurora Serverless v1 can also scale to zero capacity when there are no connections if you enable the pause-and-resume option for your DB cluster's capacity settings.

Source: How Aurora Serverless v1 works
Take this with a grain of salt, though, as I haven't tested this behaviour myself, and the docs aren't perfect. The same doc goes on to reference "no activity" without defining it:

You can choose to pause your Aurora Serverless v1 DB cluster after a given amount of time with no activity.

Which begs the question: "does an idle connection count as activity?"
I think the best hint that an idle connection counts as "activity" is that the moment a connection is needed, Aurora Serverless resumes:

If database connections are requested when an Aurora Serverless DB cluster is paused, the DB cluster automatically resumes and services the connection requests.


Terraform fails to modify DNS settings a recently created VPC Peering connection because it is not yet active I have the following configuration file:

environment/main.tf:

resource "aws_vpc_peering_connection" "sb_vpc_peering" {
  vpc_id      = var.vpc_id
  peer_vpc_id = var.peer_vpc_id
  peer_region = var.peer_region

  #Other vars
}

resource "aws_vpc_peering_connection_accepter" "sb_vpc_peering_accepter" {
  vpc_peering_connection_id = aws_vpc_peering_connection.sb_vpc_peering.id
  auto_accept               = true
}

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
  }
}

The problem here is that last block in resource "aws_vpc_peering_connection_options" "sb_vpc_peering_options":

  accepter {
    allow_remote_vpc_dns_resolution = var.accepter_dns_resolution
  }

  requester {
    allow_remote_vpc_dns_resolution = var.requester_dns_resolution
  }

This causes the following error:

Error: error modifying VPC Peering Connection (pcx-084fe8578b2935b6a) Options: OperationNotPermitted: Peering pcx-084fe8578b2935b6a is not active. Peering options can be added only to active peerings.
    status code: 400, request id: 2aa0a163-e9db-4c55-aee5-4f7ffbbf8b9f

  on ../../../aws/vpc/peering-connection-accepter/main.tf line 15, in resource "aws_vpc_peering_connection_options" "sb_vpc_peering_options":
  15: resource "aws_vpc_peering_connection_options" "sb_vpc_peering_options" {

If I give it a couple of minutes and run terraform apply again, it works as the VPC has been given time to become active.

I originally had that DNS resolution bit within the aws_vpc_peering_connection resource itself, but the same error occurred so I separated them like this but that did not fix the issue.

Do I need to somehow have some sort of sleep before applying the options?

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
  }
}


How is Ansible different from simply running a provisioning bash shell in Vagrant? A team of IT sysadmins that have exprience using shell scripting to solve their problems, are contemplating to start using Ansible instead.

Are there substantial differences and good reasons to start using Ansible vs. to continue writing shell scripts?

I never used Ansible but since a few weeks, I try to figure out what good Ansible could be in comparison with shell scrips–Which proves, at least in my case, that the haunting ad-campaigns they run are effective! After many unsuccessful attempts–which proves how their documentation fail at answering one of the most obvious question–I think I finally got it.

My conclusion is that over shell scripting, Ansible essentially offers 1. The possibility of checking that a system agrees with a desired state, 2. the ability to integrate with Ansible Tower, which is a paying system that seems to include monitoring abilities. In some important cases, like when implementing the immutable server pattern, the point 1 is probably not very useful, so the list of advantages is rather thin.

It seems to me that the benefits offered by Ansible over shell-scripting, as the documentation present them, could be sensible in a few handful of optimistic cases well covered by available modules but are small or even hypothetical in the general case. For a skilled shell-programmer, these benefits are most likely counter-balanced by other aspects of the trade-off.

But my conclusion maybe only proves how bad the introduction material is at displaying the actual advantages of this software!

Now, I propose to watch the introduction video and go randomly as a potential new user through the introduction material to Ansible an let's compare it to what a skilled shell programmer can produce in a reasonable time.

The quick start video:

There is a quick start video. It starts with a page claiming that… well these are not really claims, these are bullet lists, an artefact commonly used to suspend critical judgement in presentations (since the logic is not shown, it cannot be criticised!)

1. Ansible is simple:

1.1 Human readable automation – Specifications are technical documents, how could

  name: upgrade all packages
  yum:
    name: '*'
    state: latest

be easier to read than the corresponding yum invocation found in a shell-script? Furthermore, anybody who had contact to AppleScript dies laughing when they read “human readable automation.”

1.2 No special coding skills required – What is coding if not writing formal specifications? Ansible has conditionals, variables, so, how is it not coding? And why would I need something I cannot program, that would henceforth be inflexible? The statement is happily inaccurate!

1.3 Tasks executed in order – Well, maybe some codegolf aficionados are aware of languages that execute tasks in disorder, but executing tasks in order hardly looks exceptional.

1.4 Get productive quickly – Skilled shell programmers are productive now. This counter-argument is just as serious as the initial argument.

2. Ansible is powerful

A popular salesman trick to sell artefacts is to fool people into believing they will acquire the “power” of these artefacts. The history of advertisement for cars or isotonic drinks should supply a convincing list of examples.

Here Ansible can do “app deployment” – but shell script surely do, “configuration management” but this is a mere statement of the purpose of the tool, not a feature, and “workflow orchestration” which looks a bit pretentious but no example in this document goes beyond what GNU Parallel can do.

3. Ansible is agentless

To populate the column, they wrote in three different manners that this only needs ssh, which, as everybody knows is a daemon and has nothing to do with these agents pervading the world of configuration management!

The rest of the video

The rest of the video introduces inventories, which are static lists of resources (like servers) and demonstrates how to deploy Apache on three servers simultaneously.  This really does not match the way I work, where resources are highly dynamic and can be enumerated by command-line tooling provided by my cloud provider, and consumed by my shell functions using the pipe | operator.  Also, I do not deploy Apache on three servers simultaneously, rather, I build a master instance image that I then use to start 3 instances which are exact replicas one of the other. So the “orchestrating” part of the argumentation does not look very pertinent.

Random documentation step 1: Integration with EC2

EC2 is the computing service from Amazon, interacting with it is supported by some Ansible module. (Other popular cloud computing providers are also provided.):

# demo_setup.yml

- hosts: localhost
  connection: local
  gather_facts: False

  tasks:

    - name: Provision a set of instances
      ec2:
         key_name: my_key
         group: test
         instance_type: t2.micro
         image: "{{ ami_id }}"
         wait: true
         exact_count: 5
         count_tag:
            Name: Demo
         instance_tags:
            Name: Demo
      register: ec2

The corresponding shell-script would be essentially identical with YAML replaced by JSON:

provision_a_set_of_instances()
{
  aws --output=text ec2 run-instances --image-id …
}

or the JSON version

provision_a_set_of_instances()
{
  aws --output=text ec2 run-instances --cli-input-json "$(provision_a_set_of_instances__json)"
}

provision_a_set_of_instances__json()
{
  cat <<EOF
{
    "ImageId": …
}
EOF
}

Both version are essentially identical, the bulk of the payload is the enumeration of the initialisation values in a YAML or JSON structures.

Random documentation step 2: Continuous Delivery and Rolling Upgrades

The largest part of this guide does not display any really interesting feature: it introduces variables (IIRC, shell scripts also have variables)!, and an Ansible module that handles mysql, so that if instead of searching after “how do I create a mysql user with privileges on X Y” and end with something like

create_application_db_user()
{
  mysql --host "${mysql_host}" --user "${mysql_user}" --password "${mysql_password}" "${mysql_table}" <<EOF
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
EOF
}

you search after “how do I create a mysql user with privileges on X Y in ansible”  and end up with

- name: Create Application DB User
  mysql_user: name={{ dbuser }} password={{ upassword }}
              priv=*.*:ALL host='%' state=present

The difference is still probably not very meaningful. On that page we also discover that Ansible has a template meta-Programming language

{% for host in groups['monitoring'] %}
-A INPUT -p tcp -s {{ hostvars[host].ansible_default_ipv4.address }} --dport 5666 -j ACCEPT
{% endfor %}

When I see this, I happen to really be in my comfort zone. This kind of simple meta-programming for declarative languages is exactly the same theoretical paradigm as BSD Makefiles! Which I happen to have programmed extensively This excerpt shows us that the promise of working with YAML file is broken (so I cannot run my playbooks through a YAML parser, e.g.). It also shows us that Ansible must discuss the subtle art of evaluation order: we have to decide if variables are expanded at the “declarative part” of the language or at the “imperative” meta-part of the language. Here shell programming is simpler, there is no meta-programming, aside from explicit eval or external-script sourcing.  The hypothetical equivalent shell excerpt would be

enumerate_group 'monitoring' | {
  while read host; do
    …
  done
}

whose complexity in comparison to the Ansible variant is probably tolerable: it just uses the plain, regular, boring constructs from the language.

Random documentation step 3: Testing strategies

Last, we meet what turns out to be the first actually interesting feature of Ansible: “Ansible resources are models of desired-state. As such, it should not be necessary to test that services are started, packages are installed, or other such things. Ansible is the system that will ensure these things are declaratively true. Instead, assert these things in your playbooks.” Now it starts to be a bit interesting, but:

Aside from a handful of standard situations readily implemented by available modules, I will have to feed the bits implementing the test myself, which will quite probably involve some shell commands.
Checking for the conformity of installations might not be very relevant in the context where the immutable server pattern is implemented: where all systems running are typically spawned from a master image (instance image or docker image for instance) and never updated – they are replaced by new instead.

Unaddressed concern: the maintainability

The introductory material from Ansible ignores the question of the maintainability.  With essentially no type system, shell-scripting has the maintainability ease of JavaScript, Lisp or Python: extensive refactorings can only be achieved successfully with the help of an extensive automated testsuite – or at least designs that allows easy interactive testing. That said, while shell scripting is the lingua franca from system configuration and maintenance, nearly each programming language has an interface to the shell. It is therefore totally feasible to leverage the maintainability advantage of advanced languages, by using them to glue together the various the bits of shell-configuration bits. For OCaml, I wrote Rashell that essentially provides a hand of common interaction patterns for subprocesses, which makes the translation of configuration scripts to OCaml essentially trivial.

On the side from Ansible, the very weak structure of playbooks and the presence of a meta-programming feature make the situation essentially as bad as it is for shell scripting, with the minus points that it is not obvious how to write unit tests for Ansible, and the argument of introducing ad-hoc a higher-level language cannot be mimiced.

Idempotency of configuration steps

The documentation of Ansible draws the attention on the necessity of writing idempotent configuration steps. More precisely, configuration steps should be written so that the step sequence a b a can be simplified to a b, i.e. we do not need to repeat configuration step. This is a stronger condition than idempotency. Since Ansible allows playbooks to use arbitrary shell commands, Ansible itself is unable to guarantee that this stronger condition is respected. This only relies on the programmer's discipline and the importance of this variation of idempotency when writing configuration scripts is certainly not a novelty.

Post-Scriptum. Since this answer seems to enjoy a relative popularity, I fixed a few embarrassing syntax errors and typos. By a twist of life I also had to use Ansible two years in my work. Overall my experience confirms what I foreseen here and I hardly can think about a situation where shell scripts would have been really outperformed by Ansible. On some aspects, Ansible is just worse than shell scripting. At least the shell has functions, these functions can be mocked, it is possible to test part of all of them, so overall the shell has much better software engineering features than Ansible has. In a shell script it is also possible to process data and awk can express all what SQL can, which is very important when programming configuration – the information we are working with here is not intrinsically hierarchical, so there is a need for extracting an rewriting. Ansible is so bad at extracting and rewriting data! Treatments must be expressed with a mixture of YAMl-templating at the playbook step level and a dialect of Jinja at the dictionary member level… this is cumbersome, ugly, hard to write, hard to test and poorly documented (I regularly looked up the Jinja filter implementations!).


How to hot deploy to Tomcat with Ansible Currently I build my app with maven and use the tomcat manager to hot deploy the war file (both on windows servers).

Now I want to use ansible to move away from the manual process.

Would it make sense to build with ansible? My assumption is, that it does not.
How could I use the tomcat manager to hot deploy, triggered by ansible. I have searched the web but I did not find a solution.
Is there an other option to hot deploy the war file, which I might have overseen?

At the bottom line I found this method as stable and reliable, in case you want to deploy via ansible.

### This play deploys a webapp war to an tomcat server

- name: Copy the war file {{ webapp_name }}.war as {{ webapp_name }}.war.tmp to {{ webapp_destination_folder }}
  win_copy:
    src: files/{{ webapp_name }}.war
    dest: "{{ webapp_destination_folder }}\\{{ webapp_name }}.war.tmp"
    force: yes

- name: Remove current war file {{ webapp_destination_folder }}\{{ webapp_name }}.war
  win_file:
    path: "{{ webapp_destination_folder }}\\{{ webapp_name }}.war"
    state: absent

- name: Wait until the webapp folder {{ webapp_destination_folder }}\{{ webapp_name }} is deleted
  win_wait_for:
    path: "{{ webapp_destination_folder }}\\{{ webapp_name }}xxx"
    state: absent
  register: folder_info

- name: rename the {{ webapp_name }}.war.tmp to {{ webapp_name }}.war
  win_command: "cmd.exe /c rename {{ webapp_destination_folder }}\\{{ webapp_name }}.war.tmp {{ webapp_name }}.war"
  register: cmd_result


Single Page Apps and DevOps Pipeline? I am new to the whole DevOps process.

As a software developer with some experience in building single-page applications (SPAs) using Webpack which already takes care of the unit checks, code validation, etc, how does a SPA development process fit into the DevOps workflow/pipeline?

Do you do all the code checks on the client-side and then push compiled code into the pipeline process via a Static buildpack (ie, /dist folder) or do I push my build files into Git with a Jenkins file for CI/CD and then go through the pipeline with a server-side NodeJS buildpack?

I am wondering how much work needs to be done locally before going through the pipeline. I don't like the idea of having extra dependencies to rely on (it seems there are always issues on the server side preventing apps from getting deployed -- outdated buildpacks, errors in servers, downtimes, etc). I wonder if simply offloading all that to the client side is a good way to get an app out quicker (just push the static files via a Static buildpack).

Thanks

When starting from scratch first build a set of scripts (bash and golang) which start with a git pull to get the fresh code for a given branch then the script issues all the command line steps you can do yourself to compile the code into executable bundles.  This includes issuing Docker commands to cut fresh docker images for the various microservices.  Then a script launches all the various Docker containers.  Now the app can get fresh code pushed to domains where people can login and use the app from their client (mobile or browser) whenever a developer requests a domain needs a refresh.

The next step for us was to setup a github webhook server on each server for each domain which subscribes to all git push performed by our developers.  If a given git push matches the github code branch a domain is running the webhook would trigger launch of the above script to compile then deploy the app

All of above is just automation to replace what someone was originally manually issuing themselves at the command line.  As need appeared a new step was issued manually until it got crafted into above tooling.


How to Automate VM provisioning and setup using code? Here is what I want to achieve.
I write code(Java, NodeJs, Go) to tell the program

which Cloud Provider to choose- AWS/Azure
write code to create a instance , lets say AWS - EC2 instance under which region, security pair, ports, volumes.
Then once the VM is created , write code to ssh into the system , do yum update , install docker, do other stuff and fetch certain containers. Basically ready the system for future use but mostly I would want to deploy Docker containers on these VMs later.

My question is - to achieve the above scenario which tools should be used . I understand for provisioning of the VMs in AWS , I can use the SDK, so applies for other vendors as well , but for the setup part what would be the preferred mechanism ?

First and foremost, there are several tools for better managing and provisioning of infrastructure such as Terraform.
You could create a pipeline to create things automatically as needed (based on triggers or manual start) on Jenkins or Gitlab, your code could be created using any language using the defined cloud provider SDK or API, or the. Terraform code as previously said. I'd use the Terraform since it's way easier to manage what is there, and sincronize the current cloud state.
Also, Ansible is great to setup machines, but Terraform can do it too.


Run scripts which are stored in GitLab from Jenkins I have configured Jenkins Build Jobs and Deployment Jobs from using Jenkins shell. But I put all the commands in Shell to execute. Can I store those commands in GitLab and execute from jenkins?

If you are using Gitlab merely as a source code repository, and you are triggering the jobs when there are changes to the repository.

The Jenkins Gitlab plugin documentations states:

  This plugin is a build trigger that allows GitLab to trigger Jenkins builds when code is pushed or a merge request is created. Configuration done on a per-job basis.

So, you can trigger the builds. But to answer your question:

  I put all the commands in Shell to execute. Can I store those commands in GitLab and execute from jenkins?

The answer is yes, but there is some leeway. It depends on how you've configured the jobs. If they are freestyle jobs, have them execute a shell command running the script in your repository. You can do this via the web-interface the Jenkins job editor.

However, I wouldn't recommend this as best practice. Instead, I would recommend having a pipeline description in the repository. See the plugin docs on github for more details on configuration.


Ansible playbook fails with: no test named 'success' I have an Ansible Playbook that is used to configure WSL on my Windows Laptop, having rebuilt my laptop recently I needed to run the playbook again, however it is failing with the following message:

The conditional check 'aptitude_installed is success' failed. The error was: no test named 'success'
  line 1

The error appears to have been in '/mnt/c/source/richardslater/workstation-setup/wsl/plays/wsl.yml': line 15, column 5, but may\nbe elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:

  - name: ensure aptitude is installed
    ^ here

The context from the playbook is:

tasks:
- name: check if aptitude is installed
  shell: dpkg-query -W -f='${Status}' aptitude | grep 'install ok installed'
  register: aptitude_installed
  failed_when: no
  changed_when: no

- name: ensure aptitude is installed
  command: apt-get -y install aptitude warn=False
  when: aptitude_installed is success

The output of dpkg-query -W -f='${Status}' aptitude | grep 'install ok installed' is:

install ok installed

and ansible --version

ansible 2.2.1.0
  config file = /mnt/c/source/richardslater/workstation-setup/wsl/plays/ansible.cfg
  configured module search path = Default w/o overrides

and pip show jinja2

Name: Jinja2
Version: 2.8
Summary: A small but fast and easy to use stand-alone template engine
written in pure python.
Home-page: http://jinja.pocoo.org/
Author: Armin Ronacher
Author-email: armin.ronacher@active-4.com
License: BSD
Location: /usr/lib/python2.7/dist-packages
Requires: MarkupSafe

I'm not entirely sure how it ever worked, either that or something changed since I built this playbook, any ideas on how to fix?

You use pretty old ansible, maybe worth to try a new one. Although tests "succeeded" and "success" should be in 2.2 too.

But main problem I think it's failed_when: no in your task. It makes test when: aptitude_installed is success completely useless, it will be always true because failed_when: no marks all tasks as successful.

If you don't want to stop on task, but still to have an idea how it went, you should use ignore_errors: true, not failed_when: no. With ignore_errors: true you can both continue your playbook and inspect a real tasks results.


Organizing Chef cookbooks Is it 100% required to store all the cookbooks under chef-repo? This seems a little bit inconvenient for me, I'd prefer to store solution cookbooks in the application codebase, or just as a standalone git repos.

I know that tools like knife rely on configuration files to be present in .chef, and it frustrates me a little bit too.

No, it is not, the chef-repo is the legacy way back to chef 10.

Knife allows working on multiples directory with the -o option. Berks work from current directory.

You can also work around the default .chef directory by using the KNIFE_HOME environment variable too.

The current recomendations is indeed a repo per cookbook (or alongside another app)


What can Vagrant, Puppet, Docker, Chef do for a Full stack Web developer? First of all let me say that I'm aware of related questions here in SO:

Vagrant, Docker, Puppet, Chef
Vagrant + puppet + docker
chef-server - chef-solo - vagrant - puppet... which is correct for me?

Or articles out there:

https://www.upguard.com/blog/puppet-vs-chef-battle-wages

But I'm having trouble understanding real benefit they provide for a web developer (e.g. Full stack developer with (PHP/react)). You know? None of them is that clear for me in:

what facilities they could provide & how they make my job easier?
When do they become semi vital for project success & non-self-repeating activities?

Would you mind clarifying these concepts/techs from my POV? If you mind, please avoid comparing with routine "Vs." literature & Try to introduce real-life good-parts. A brief explanation from anybody would sufficient.

First of all, I strongly advise against "feature comparisons" blog post for similar software, they're quickly outdated and I'll try to keep this answer generic for a system configuration manager (SCM) and let docker out of the talk for the first part.

What it can brings you:

Reproduction of configuration from environment to environment
Versioning of the configuration
Enforcing the configuration

To get a real life example for a PHP application you'll need:

an operating system
a webserver
php libs
configuration of your app for external services (smtp, database IP, etc.)

What a SCM can provide is starting from a minimal base OS:

taking care of installing the webserver (apache/nginx)
installing PHP (either by package or source)
installing the necessary libs
Setting up your site config (vhost in apache)
Setting up your php.ini with any tweaks needed
deploying your app from a repository (from git to nexus, wide range of choice)
Writing your application configuration (here can be the smtp or database server for this environment)
Starting the webserver
Eventually running some smoke tests on your app.

Now if someone comes to connect to the machine and do a manual change to any of the configuration, the goal of a SCM is to keep the machine in its desired state, at next run, the change will be detected and the file changed will be put back to its desired state.

This has the advantage of enforcing any change to be put in the desired state description and not be forget between environments. Usually chef or puppet are set up to run on a periodic schedule, default for Chef is 30 minutes.

Now the big difference with docker is that you will do the same thing, installing you middleware, libs, forcing a templatized configuration, etc.
Once in the runtime phase, if there's a breach in your app and an attacker use it to tweak your config or modifying your webserver configuration it can stay unnoticed for a while if it doesn't break the app.

A SCM will revert the changes if you use it properly it will even remove unwanted sites in the sites-enabled directory of apache and thus will raise the complexity for an attacker.

Likewise if your webserer dies, the container will stop and unless you have a system to monitor it an relaunch it you're down. A SCM will notice the service is stopped and restart it at its next run, less immediate than runit but it will correct a rotate script which didn't properly restart the service (like the default apache logrotate conf on Ubuntu  which may time out and let your apache stopped)

A SCM may be interesting even to create your docker containers, you know you'll have the same behavior on a centos or ubuntu machine (most community code handle using the proper package names if you go this way) and so it will remove problem of edit to package names in a dockerfile.

The main idea behind a SCM is to manage your infrastructure as you manage your application, code it, version it, test it and be sure it will always behave the same.

If you rely on human procedure for configuration of the middleware/libs/app config you can be sure there will be a step forget during the deploy process once in a while, and spotting this problem can be really hard. With a SCM you prevent this omission.


Jenkins Promote Build across different pipeline? In my workplace, we are using a monolithic repo. It contains many project and micro services that run on different Jenkins pipeline. I know that using Promoted Build Plugin, we can promote build of tested artifact.

However as our projects depend on projects that run on a separate pipeline, I am wondering if the Promoted Build Plugin is able to promote artifact to a different pipeline. Or can the pipeline that is running head over to a separate "place" to take the last tested artifact and use it as part of its own pipeline criteria?

The reason we want to do this is because of integration test that depend on the existent of another build artifact. We want to be able to test on the latest build artifact that is on another pipeline. Would be even better if we can select base on the tag/version.

In my opinion you should treat each pipeline dependency as any other dependency.

Set up an artifact repo like nexus or artifactory to be used as source of artifacts.
This way you can ask for latest or tagged version of an artifact inside your pipeline and push to this repo your own artifacts when the build succeed.


Cookbook get and set dynamic URL There is a static Artifactory URL being used to grab a semantically versioned artifact and deploy it to JBoss.  The deployment aspect of the cookbook is already fleshed out.  However, I would like to make the URL "dynamic".  In other words, get the most recently published artifact from Artifactory.

Example URL
https://myartifactory.com/releases/com/package/helloworld/1.0.0/helloworld-1.0.0.war

A Jenkins pipeline exists for this artifact that deploys to Artifactory.  So, if 1.1.0 were to be released, it's URL would look like the following:

1.1.0 URL
https://myartifactory.com/releases/com/package/helloworld/1.1.0/helloworld-1.1.0.war

You can see that the directory in Artifactory changes, as well as the name of the artifact.  How can I set up the cookbook to always grab the latest version from Artifactory?

You should use of the Retrieve Latest Artifact endpoint. It uses the repository layouts to know what is the version in your artifact path, so you want to make sure those are set right for you. In this case, it's a standard Maven layout, which is the default for Maven repo, so you're all good.


What is the term for a deployment designed to make a future cutover seamless? I'm currently working on a new major version (v2) of an application meant to replace the current production version (v1). This redesign carries with it changes to the front-end, public API layer, internal API layer, and database — the whole kit and kaboodle.

While it is easy to have active v1 and v2 front-ends and public API (which I'll call the "front half" for brevity's sake) simultaneously in our lower environments, for various reason, this is NOT possible for us to do with the internal API and database (which I'll call the "back half").

The v2 redesign necessitates changes to the back half that cause breakage in the v1 front half. However, in this particular instance, by making a minor change in the v1 front half, this breakage can be avoided. As such, it is possible for us to deploy this v1 "shim" along with the changes to the back half to production. When the time comes, we will be able to cut over to the v2 front half without the back half needing any further deployments.

Is there a name for this particular type of deployment, where a shim is deployed to an existing app to make it work with an updated back end, with the goal of making a future cutover seamless?

Taking my definition of blue/green deployment from this informative blog post, I believe this is a distinctly separate kind of deployment.

... by making a minor change in the v1 front half, this breakage can be avoided.

The above excerpt of this queston reminds me of something similar from around the late 90s, say 1996-1999 (when zillions of ITers were preparing for Y2K ...). In those days, new software releases of huge software vendors would come with release notes that included things like either of these:

"this release is to make this software Y2K tolerant " (= allows the software to contnue to work as of Jan 1, 2000, at least for a while, though it would keep showing dates with 2 digits for the year, like 00, and not yet 4 digits, like 2000).
"this release is to make this software Y2K ready " (= allows the software to continue to work as of Jan 1, 2000, without any (known) limitation because of the change of century from 19 to 20).

Y2K tolerant softwares would typically also include some sort of magical cut-off value, e.g.: years from 70 (when even MS DOS did not exist ...) to 99 were assumed to be from 1970 to 1999, while anything from 00 to 69 were assumed to be from 2000 to 2069. Such assumption was also why such softwares were required to be superseeded by some Y2K compliant release later on (in which those assumptions were obsoleted).

With the above in mind, the term you are asking for could be something like a "V2 tolerant release", which at some point in the future would then be followed by a "V2 ready release" (= your actual V2 release).


saltstack: archive.extracted template jinja I have an archive on my master and want to extract it on the minion. For this it is fine I use :

  archive.extracted:
    - name:  'c:\PACKAGE'
    - source: salt://myfile.zip
    - archive_format: zip
    - enforce_toplevel: False
    - failhard: True

the problem is that I need to apply jinja template on some files of the zip file content.

But there is no template property on archive.extracted and I can't find a way to apply jinja template after it is extracted on minion server...

any idea ?

There is no much choices regarding your situation, I see two of them :

You ask your dev dpt to add your jinja templating to their builds (which may be hard or even impossible)
You can use salt module such as file.append or file.replace to add / replace your jinja code inside (this is not very clean that's the least we can say)

If you'd share an example that may help us to give some good advice


ELK - micro service and network latency monitoring Does ELK stack provide  micro service and network latency monitoring in kibana?

Zipkin provides details about service request and service response duration.

In behind ELS stack should trace span events:

cs - Client Sent

sr - Server Received

ss - Server Sent

cr - Client Received

ELK stack does not provide monitoring. It only provides reporting unless you configure additional add-ons such as ElastAlert.

ELK also only reports (or alerts if configured) on the data that you feed into it. So to turn the question around:

  Do you have your network devices configured to send micro service and network latency logging information to your ELK stack?

If yes, then the answer will be yes. If no, then the answer will be no.

ELK is nothing more than a system for processing and reporting metadata and generating structured data from plaintext logs, so it will do whatever you configure it to do.


Get all Deployments referencing given ConfigMap by the ConfigMap's name Suppose I have a ConfigMap:
apiVersion: v1
kind: ConfigMap
metadata:
  name: london-tz-config
data:
  SERVER_TIMEZONE: "Europe/London"

I also have about 50 distinct Deployments. Let's say that 20 of them use the london-tz-config ConfigMap to set their environments, like this
  template:
    metadata:
      labels:
        app: echo-app
    spec:
      containers:
        - name: echo-app-container
          image: ealen/echo-server:latest
          ports:
            - containerPort: 8080
          env:
            - name: SERVER_TIMEZONE
              valueFrom:
                configMapKeyRef:
                  name: london-tz-config    # Reference our ConfigMap here
                  key: SERVER_TIMEZONE

I don't know which Deployments use which ConfigMaps at any given time without manually inspecting the cluster.
Is there a way to ask Kubernetes to show me all Deployments that contain references to a given ConfigMap by its metadata.name attribute?
Either kubectl or the Kubernetes API would be okay.

You can use kubectl get -o json and parse the output using jq to iterate over the deployments, matching any desired configMapKeyRef.name and returning a uniq list of deployments.
This should work:
kubectl get deployments --all-namespaces -o json | jq -r '.items | map(select(.spec.template.spec.containers[]?.env[]?.valueFrom.configMapKeyRef.name == "london-tz-config" ) | .metadata.name) | .[]' | uniq


How to add ECS attributes to an instance using terraform I heavily use ECS Attributes on our containerized infrastructure. I couldn't find terraform docs to achieve this. Do I need to execute aws cli commands manually to apply those attributes after creating the infrastructure?

Terraform docs are pretty comprehensive, so if it’s not in the docs it’s probably not implemented yet.

However, they’re very responsive to feature requests posted as GitHub issues, particularly those that indicate that the feature is available via the AWS CLI (or more specifically, the AWS Go SDK). In my experience, feature requests I’ve raised have usually been available in a new AWS provider release within a month or so.

I’d suggest doing up a new issue here:
https://github.com/terraform-providers/terraform-provider-aws/issues

(I did do a quick search to see if ECS attributes have been raised before and couldn’t see any at a quick glance, but you may like to as well!)


Docker In Kubernetes Deployment I am using a third party library that creates sibling docker containers via:

docker run -d /var/run/docker.sock:/var/run/docker.sock ...

I am trying to create a Kubernetes deployment out of the above container, but currently getting:

  Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

This is expected because I am not declaring /var/run/docker.sock as a volume in the deployment yaml.

The problem is I don't know how to do this. Is it possible to mount /var/run/docker.sock as a volume in a deployment yaml?

If not, what is the best approach to run docker sibling-containers from within a Kubernetes deployment/pod?

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


What are some reasons for using an Ansible role for Certbot vs. Ansible's native `acme_certificate` module? To get Let's Encrypt HTTPS certificates for their Web sites, I'm aware of quite a few folks using a particular role, which wraps Certbot, a standalone application not native to Ansible.

There is, however, a native Ansible module called acme_certificate, and at least one accompanying role that wraps it.

It seems to me that it would make sense to native Ansible modules whenever possible, but are there reasons for not doing so in this particular case?

Thanks for linking your question. Here's the github thread for reference: https://github.com/geerlingguy/ansible-role-certbot/issues/87

There are many different ways to get certs from a CA. certbot (what this repo uses) is just one of the ways which uses letsencrypt as a certificate authority. acme_certificate is more generic and if you can't use letsencrypt then it might be a good tool to check out for http-01, dns-01 and tls-alpn-01 challenges.

Certbot is a great way to manage certs from letsencrypt, so if you're needs are fairly standard this is a good choice. It's a higher level package and will also handle auto renewal (assuming you enable it).

it is possible to do renewals with acme_certificate. You could do something similar with letsencrypt https://docs.ansible.com/ansible/2.5/modules/letsencrypt_module.html . certbot just handles a lot of this for you, specifically for letsencrypt.

Personally I think using certbot to help manage certificates is simpler, but that's up to you. certbot is an application that handles the verification process for with the certificate authority, which is very handy. With acme_certificate you'll essentially be doing that yourself. It also automatically can set up automatic renewals which is very nice.


Disable a Jenkins pipeline on failure? Issue with a central deployment job Consider a structure of X micro services and 2 environments; staging and production.

Each of these micro services is represented by a separate git repository, when a merge to master happens on any of these services, a jenkins job is triggered to test the code locally and if it's successful - trigger a deployment pipeline.

The deployment pipeline is a single job with the following steps:

build and test locally -> deploy to staging -> run overall system tests on staging -> deploy to production

Again, this downstream pipeline can be triggered by any of the X micro services.

The issue I have comes from the following scenario:

service A code is updated and merged to master, the code is built and tested -> deployment pipeline is triggered -> code is again built and tested successfully -> service is deployed to staging -> tests against staging fail -> pipeline is aborted and deployment to production is avoided

this scenario causes a difference of versions between staging and production. The larger problem happens when this failure goes unnoticed and isn't rolled back, then subsequent services that trigger the deployment pipeline will fail the tests on staging because of the previous deployment and the gap between staging and production will just keep growing until someone rolls back/fixes the failing tests and either triggers all the deployments again, or manually syncs between the environments.

This is of course not ideal, and the immediate solution seems to be "disabling" the deployment pipeline after a certain threshold has been crossed (weather it be a single failure, or a number of them), but this doesn't seem to be possible to achieve using Jenkins.

Is there actually a way to disable a jenkins job dynamically? Is there another obvious solution that comes to mind with this architecture?

There is a "Jenkins Disable Job" plugin, which you can use in your pipeline to disable the job on failure.

You will be able to use this plugin for single failure or to disable after multiple failures.

https://wiki.jenkins-ci.org/display/JENKINS/Disable+Failed+Job+Plugin


AWS ElastiCache Redis DNS error - Name or service not known The Problem & The Question
I'm trying to create an AWS ElastiCache Redis-flavored cluster and connect to it from an instance in the same VPC. When I create the cluster initially, I can connect to it just fine via redis-cli. If I wait a day or two and then try to connect to it again via redis-cli, I get the following error:
$ redis-cli -h <aws-elasticache-cluster-primary-endpoint>
Could not connect to Redis at <aws-elasticache-cluster-primary-endpoint>:6379: Name or service not known
not connected>

I should be able to connect again with no issue. Why would I be getting DNS errors the next day when it worked initially? Nothing has changed about the cluster since I created it. How could I fix this?
Steps to Reproduce

ElastiCache Dashboard -> Redis -> Create.

Set the following options:

Option
Value

Cluster Engine
Redis

Location
Amazon Cloud

Engine version compatibility
6.x

Port
6379

Parameter group
default.redis6.x

Node type
cache.t3.micro

Number of replicas
0

Multi-AZ
false

Subnet group
default

Security groups
default

Encryption at-rest
false

Encryption in-transit
false

Create.

After creating, verify you can connect to the cluster with:
redis-cli -h <aws-elasticache-cluster-primary-endpoint>

Disconnect.

Try reconnecting with the same redis-cli command a few days later. You should see the errors shown in the section above.

Additional Information
nping
$ sudo nping --tcp -p 6379 <aws-elasticache-cluster-primary-endpoint>
Failed to resolve given hostname/IP: <aws-elasticache-cluster-primary-endpoint>.  Note that you can't use '/mask' AND '1-4,7,100-' style IP ranges
Cannot find a valid target. Please make sure the specified hosts are either IP addresses in standard notation or hostnames that can be resolved with DNS

nslookup
$ sudo nslookup <aws-elasticache-cluster-primary-endpoint>
Server:         75.75.75.75
Address:        75.75.75.75#53

** server can't find <aws-elasticache-cluster-primary-endpoint>: REFUSED

Reachability Analyzer
I followed AWS' instructions for testing connectivity from my EC2 instance to the ElastiCache cluster. The results I got back for the connectivity were:

Reachability Status
State

Reachable
Succeeded

Cluster Metrics

Metric
Value

CPU Utilization
~1.000%

Engine CPU Utilization
~0.283%

Database Memory Usage Percentage
~1.093%

Local Wireguard configuration
[Interface]
PrivateKey = <value>
ListenPort = 21841
Address = 10.0.0.2/32
DNS = 9.9.9.9 # 75.75.75.75 75.75.76.76

[Peer]
PublicKey = <value>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = <public-IP>:51820

It could be due to a "VPC DNS throttling", you can find more information on the official documentation.
https://aws.amazon.com/premiumsupport/knowledge-center/vpc-find-cause-of-failed-dns-queries/


When setting up Foreman should this be setup on the same server as my puppet ro ansible master? I am trying to setup Foreman to interface with my Puppet Master and Ansible installation.  Do I need to have this on the same server or can it be by itself and make API/port calls?  I am new to this so I don't know.

The Foreman comes with a Puppet Master whether you like it or not since The Foreman uses puppet as part of it's installer. This can't be disabled and The Forman will leave it behind and running - so you might as well use what is deployed anyway and make the Puppet Master and your Foreman server one in the same. You can keep your Ansible installation elsewhere, however The Forman integrates with Ansible and has Ansible callbacks
 so it might make sense to keep your configuration management stack all in one place.

On the other hand, The Forman can be a big install with lots of moving parts that seem to get gummed up from time to time,
 so you might be better off putting together an Ansible playbook to redeploy your Foreman stack since Ansible can also manage your Forman resources - so this would be a good argument to keep the Ansible bits seperated.


Is running load balanced autoscale apps cheaper on AWS Kubernetes than just using EC2 resources? We're running like 100+ servers on AWS EC2 with like 20 microservices all load balanced and autoscaled with 2 to 3 instances.

The cost has become....very significant.

I'm wondering if migrating these to Kubernetes or ECS would be cheaper?

From your comment I assume a cpu load under 5% in average considering all instances together.

Each of your actual instance can be a pod on a kubernetes node, using quite larger instances you can reduce to a dozen of m3 or m4 machines with a single (or two) load balancer in front for the same quality of service.

You'll have machines used at 70% (ideally) and using an autoscaling group with a scaling policy to take care of spinning up a new node in case of burst.

The main idea is that you should be able to host on fewer machines with a better average load and thus reduce your cost, the first net gain is the reduction in number of load balancers, but this could be debated with Application Load balancers which allow to route by context or host.

Be warned there's a learning curve with kubernetes, but according to your description this sounds the perfect use case.

Beware of the 'all in k8s' trap, some things are better handled out of kubernetes, like large database systems or CPU/memory intensive task as they disrupt the load repartition and brings some more complexity. I.e: keep both possibilities, k8S and usual ASG/instances based hosting.


How to build all projects in a monorepo by starting a build in Jenkins? We have a monorepo that consists of multiple projects that contain a build file. How to ensure that all these projects will be built when the job is triggered?

One solution I am thinking about is creating a shell script that detects whether the folders contains a build script, add the name to a set, iterate on this set and trigger a build for all of the projects. I wonder whether this is a good approach, but it feels cumbersome.

Build tools like maven or gradle could benefit you greatly here. It would do exactly what you have in mind as long as you have child project definition (with a build.gradle in gradle or pom.xml in maven).

I would not recommend the script as it would mean you have to maintain and tweak it in the future. Instead, investing in build tools can give you great ROI as they do much more than just build.

At the end if you cannot integrate a build tool, go for the script. It is a good idea also.


How to perform logging of Ansible crons in Kibana? I have set up some crons in Ansible, and I want to log when they start, finish, and if they fail.

How I could do it?

I don’t know so much about Ansible.

Ansible is an automation tool, so it can automate things you can do by hands.

But as far as I know no existing cron-like services support sending logs to elasticsearch (Kibana is just a viewer, btw) out of the box.

So at first, you should create some wrapper script that will execute your actual job and send it's result to elasticsearch.

An then schedule this wrapper script via Ansible.

Or choose another route, setup syslog forwarding to logstash/elasticsearch on your target box to collect all logs, then just filter your desired cron jobs.


What are best practices and/or tools for updating AMIs on a regular basis? I have a Master-Workers style computation model. And, I launch the workers via an AMI through an Ansible playbook.

The workers' AMI has all the necessary configs needed for doing the computation (which is mostly a pipeline of ML tasks).

However, we keep updating and optimizing our algorithms and ML models almost on a regular basis, which means I have to keep my Worker AMI's up-to-date.

So, is there a tool or a technique which would help me do that?

Also, is it a scalable practise, or is doing the containerized way better?
[By which, I mean launching an EC2 instance and pulling a container and do the computations inside a container].

We are planning to automate this process for our Jenkins EC2 slaves.

Currently we have to manually update the AMI ID every time we build a new AMI, but by taking advantage of the config.xml file where Jenkins store all its configuration, we should be able to automatically update the AMI value in this file and then restart Jenkins to take those changes into effect.

EDIT: see comments below for a better way to make those changes rather the config.xml file


Does Kubernetes Ingress use NodePort? When using a Kubernetes LoadBalancer or Ingress, is the normal NodePort used as the underlying connection point? I.e. does the external-to-kubernetes load balancer implementation (used even when Ingress is in play) communicate with the Service in the cluster via NodePort or is there some other "magic" way that is used?

I ask because in reading about kubernetes, I have found some sources that have almost implied that NodePort is somehow unreliable ("if you don't need your services to be available all the time"), and if NodePort is the mechanism underlying other load balancer implementations, then it should be safe to use, given an understanding of its particularities.

For your first question:

  When using a Kubernetes LoadBalancer or Ingress, is the normal
  NodePort used as the underlying connection point?

Technically it depends on the cloud network for LoadBalancers (e.g. Google Compute Engine does not technically require this although one may be created).  However, I believe a NodePort and ClusterIP are generally created.

For your question on the usage of NodePorts:

The short answer is yes, they are safe to use if you know what you are doing.

The longer answer is that NodePorts are great for debugging and development but have some issues in production:

You can only have one service on a port.
HTTP/HTTPS traffic may be routed through a non-standard port.
The port will be opened on all nodes.

However, NodePorts do provide some nice flexibility (from Kubernetes documentation):

  Using a NodePort gives you the freedom to set up your own load balancing solution, to configure environments that are not fully supported by Kubernetes, or even to just expose one or more nodes’ IPs directly.


What is an artifact (or artefact)? The question about "What is an artifact repository?" contains an answer with an interesting explanation about the repository part of it.
And from reading the entire answer, I am not sure what exactly an "artifact" means in the context of DevOps.

Any suggestions?

Ps: From one of the answers I seem to understand that maybe artefact is what I'm wondering (confused?) about ...

Wikipedia has a very good answer to this question. Artifact, sometimes also called Derived Object, is a product of some process applied to the Code Repository. Originally they were called Build Artifacts, but as more processes were applied other than build to create them, the first word was simply dropped.

The major distinction is that artifacts can be recreated from the code repository using the same process, providing you have preserved the environment in which the process was applied. As this process can be time consuming and the environment can be preserved imperfectly to be able to recreate the artifacts in the exact same way, we started to store them in Artifact Repositories.

Storing them apart from Code Repository in an Artifact Repository is a design decision a DevOps engineer would make. Some companies, namely Perforce, suggest to use their Code Repository as Artifact Repository as well. There are different requirements in terms of access, auditing, object sizes, object tagging and scalability on each repository and so depending on situation it is often better to use two distinct products. For example Git repositories are copied in their entirety to every development machine and so storing artifacts in the code repository would increase its size beyond all reason, although lately there are ways to mitigate this. Another decision to make is which artifacts to store. Some companies store even intermediate artifacts as individual object files, to speed re-builds, others store simply just the final binaries. Not all artifacts have the same value. Artifacts resulting from a release build could have different requirements than artifacts resulting from a developer build.

Most common artifacts are results of the following processes: Configuration, Preprocessing, Compilation, Linking, Automated Testing, Archiving, Packaging, Media files creation and processing, Data File Generation, Documentation Parsing, Code analyzing, QA, etc.


Is a ReplicaSet pulling a fresh image at every spin up? I inherited an app without a ton of handoff information, and there's a Kubernetes setup with ReplicaSets and KOPS (and based on Docker containers). I am pretty new to Kubernetes

Whenever one of the associated servers goes down, a cloned server is immediately spun up, which is working as desired.

However I am looking to make some persistent changes (uploading a some new files to the API, changing some environmental variables) to the setup, and my understanding is that I'll probably need to modify the images pulled to do this. Persistence is setup via PersistentVolumeLabel and openlayer

Is this correct?

I am trying to pull the images down locally so I can modify them, but getting an authentication required error - I have about a dozen private keys, so I assume the credentials are in one of them - is there a way to see how the ReplicaSet is pulling the images down?

Sorry for any confusions - I am very new to Kubernetes and this level of DevOps - I am used to much simpler and less scalable (so like a couple servers and a load balancer) type setups, not this type of DevOps.

my understanding is that I'll probably need to modify the images pulled to do this.

Yes and no. It depends on how your ReplicaSet - specifically the associated Deployment - is configured. You can see the corresponding YAML configuration by doing

kubectl -n yournamespace get deployment yourappdeployment -o yaml
# or
kubectl -n yournamespace describe deployment yourappdeployment

Which will give you information about environment variables, images used, volumes, secrets, etc.

  I am trying to pull the images down locally so I can modify them

Pulling an image down and modify it in-place won't be of much help, except if you run a container based on this image and use something like docker commit yo actually update the image. Even if you do that, the Kubernetes objects may override aspects defined in your image (such as environment variables)

  is there a way to see how the ReplicaSet is pulling the images down?

Yes, first output the details of your ReplicaSet:

$ kubectl -n yournamespace get replicaset yourreplicaset -o yaml

kind: ReplicaSet
spec:
  ...
  template:
    ...
    spec:
      ...
      containers:
        ...
      imagePullSecrets:
      - name: some-secret-name

imagePullSecrets is the secret which should contains the credentials to pull your images. You can retrieve the data with:

$ kubectl -n yournamespace get secret some-secret-name -o yaml

kind: Secret
...
data:
  .dockerconfigjson: eyJh...VeryLongBase64String

This is Docker authentication data encoded in Base64. You must decode them:

$ echo "eyJh...VeryLongBase64String" | base64 -d

{"auths": {"registry.yourcompany.com": {"auth": "AnotherBase64EncodedString"}}}

Decode the auth value and you'll have your Docker registry login/password

$ echo "AnotherBase64EncodedString" | base64 -d

username:password


Reading two Repos in Azure Build pipeline I created a Build pipeline in Azure using classic editor and selected empty job instead of using any template. This way provides option to connect only one repository at once. My requirement is to connect two repositories at once in the build pipeline and bring files from both of them to run some testing.
There are so many templates available to chose from but I am not sure which is the right one to select, with which I can connect two repositories at the same time. I did Google for help and found that I could use Artifact with the combination of NuGet or nmp. I don't know how does that work.

I also use the classic editor, and I have implemented this for our builds. My use case was that I have a set of common set of build/release scripts stored in their own repository, and I want the ability to bring them into the application builds that I am executing.

I created a custom Task Group with an Inline PowerShell script to do this:

# Reference: https://blog.rsuter.com/script-to-clone-all-git-repositories-from-your-vsts-collection/
Write-Host "Cloning MyRepo from Azure DevOps..."

$sourcesDir = $env:SYSTEM_DEFAULTWORKINGDIRECTORY
Write-Host "Source directory: $sourcesDir"
$repoDir = Join-Path -Path "$sourcesDir" -ChildPath "MyRepo"
Write-Host "Target directory: $repoDir"

$url = "https://dev.azure.com/my_org/my_team_project/_git/MyRepo"

# Since using PAT, don't need real username, just non-empty username. Use "x".
$username = "x"
$pat = $env:PAT # passed into inline script as environment variable
$credentials = ("{0}:{1}" -f  $username, $pat)
$urlWithCreds = $url -Replace "://", ("://{0}@" -f $credentials)
Write-Host "Clone URL: $urlWithCreds"

git --version
git clone --progress $urlWithCreds
Set-Location "$repoDir"
git checkout master
git log -1 # show the latest commit

You will have to create a PAT with code permissions and pass it into the script as an environment variable. This task will clone the repository to a directory of the same name within your existing repo.

Putting it in a task group allows me to manage it in one place, and then all my more complicated build scripts can be under version control.

There is an active feature request for the capability to source from multiple repos. It looks like it is in the roadmap: https://developercommunity.visualstudio.com/idea/365522/allow-tfs-build-to-depend-on-multiple-repositories.html


Cross-CI on Windows and Mac I am deploying CI with several runners - however they are all based on the Docker executor on Linux. Is it possible to use Linux runners to test applications on Windows or Mac instead?

I understand I could use the VirtualBox executor and have a MacOS/Windows image, however I fail to understand if it is possible to do this without acquiring a license for MacOS or Windows (maybe there are free images for CI available?)

My actual initial question was geared towards running Windows/MacOS images inside a docker container on Windows - is it possible? I assume it isn't because we are still using the Linux kernel but would like confirmation.

There are some fundamental misunderstandings in your bullets which makes your question unclear:

Apple will not allow you to develop/build using a virtual system.  I believe this is a legal constraint.  That said, you can run pretty much anything in VirtualBox as long as you have a legally provided image (e.g. a Linux image).
You can only run the Windows base images if you are running Windows Containers which will be incompatible with MacOS systems.  If you want to build on MacOS using Docker you will need to use Linux containers.

However, you can run your continuous-integration runners across Windows and Mac.  This is one of the major benefits of implementing runners in Docker for your CI tool.  Now if you have agents on Windows, MacOS, or even Linux, you can get a consistent build experience by using Docker. This official GitLab article has more about setting this up.


Prevent misspelled variables passed to Ansible roles I'm looking for strategies to mitigate silent errors related to misspelled or otherwise mistyped variables being passed to Ansible roles.

So for example, I have a role with a defaults/main.yml:

foo_version: "1.0"

Within the tasks/main.yml:

- get_url:
    url: "https://foo.com/foo-{{ foo_version }}.tar.gz"
    dest: /tmp/

Now in my main playbook, if I do this, it will install the default version, 1.0:

- include_role: name=foo

If I do this, it will install version 2.0:

- include_role: name=foo
  vars:
    foo_version: "2.0"

So far so good. But if I do this by accident, it will install 1.0 without my realizing it:

- include_role: name=foo
  vars:
    fooo_version: "2.0"

The only "solution" I've thought of is to remove the defaults/main.yml, in which case it would fail in the last case because foo_version would remain undefined. But then I can't take advantage of the benefits of having defaults.

Are there other solutions? Thanks!

Q: " Prevent misspelled variables passed to Ansible roles ... remove the defaults/main.yml, ... But then I can't take advantage of the benefits of having defaults. Are there other solutions?

A: Yes. Tell include_role to read other file defaults_from. Fit the content of this file to your needs. For example

- include_role:
    name: foo
    defaults_from: main_special.yml
  vars:
    fooo_version: "2.0"


How to Save and Restore the Iptables rule and configuration from file? I want to save the current iptables configuration to a file and restore it from a file.
I have a lot of rules and modifying the rules really hard for me.
So, how can i do that?!

If you want to modify the configuration and rules, so you must save the current configuration to a file.
So step one is to save the rules configuration by typing the following commands:
$ sudo iptables-save > /root/my-iptables.rules

To restore it just use the command iptables-restore:
$ sudo iptables-restore < /root/my-iptables.rules

⚠ When you changed the existing rules after saving the file, You should save it again or change the existing file and restore it from the file.


Azure DevOps service connection: lifetime of service principal I have a hard time understanding the lifetime of the service principal created in Azure AD when creating the service connection between Azure DevOps and Azure. I do it like this:

I pick the Azure Resource Manager

And then i choose the recommended

Hereafter I fill in the blanks

I now have a valid service connection and I can deploy from DevOps to Azure. The only thing i need is a user with enough rights to do this. I can even see the service principal in Azure where it tells me that the client secret will expire in two years:

What i dont understand:

does the service connection then stop working when the secret expires? Or will DevOps somehow extend the expire date?
i cant read this anywhere, so it is up for my own interpretation on how i understand the "service principal" concept, but if the user used to create the principal gets disabled or deleted, then the service principal will persist, correct?
if 2) is correct, then when will the principal get deleted? When the scope of the principal gets deleted? Or when the service principal itself gets deleted?

I will try to elaborate a lite about those topics.

When secret expires and you got error, you have to refresh connection. Go to Edit dialog for connection and save without any changes. Described here: Azure devops service connection expired and cannot edit/renew

But I have already tested scenario when I delete all secrets assigned to service principal used for the Azure DevOps connection. And it is still working. So I can assume, that it depends on how you create connection (automatic or manual service principal). When created with automatic path, it doesn't depend on secrets.

On the other hand, when I add connection with manually providing service principal, then delete all secrets, the connection stops working.
Yes, the service principal will exist. But best practice is to set up more then one Owner of the service principal. If the only one service principal owner is deleted, you need to have higher permission to manage all service principals.
Service principal will not expire itself, only secrets generated for it. To delete service principal object, you have to do it manually.


Jenkins shows "No changes in any of the builds." Description

Jenkins job was made and configured to build release branch which already existed and had changes on it before first build. Job also monitors for push on BitBucket and starts building if something is pushed to the release branch.

Problem is we didn't made any changes on release branch, instead we were rebasing it on development and pushing it which triggered builds but it shows "No changes in any of the builds." in Changes menu.

Question

Is there special configuration for Jenkins which allows it to handle rebase commits and show changes that occurred to that commit comparing to previous build?

Temporary workaround

Instead of calculating changes between builds compare changes against specific branch.

Open job configuration
Go to Source Code Management -> Git -> Additional Behaviours
Add Calculate changelog against a specific branch
Enter name of repository (origin in my case), and branch (master in my case)

Now instead of showing only new changes, each build will show all commits in release branch that are different comparing to master.


How granular in purpose should FaaS functions be? For clarification, when I say "FaaS" I am referring to serverless offerings such as AWS Lambda and Google Cloud Functions.

I have a specific case in mind that I'll describe but I would very much like to hear about any guiding principles in this area as well.

I have a Google Cloud Function that is currently doing some image processing. The flow looks like this:

JSON file containing several base64 encoded images is uploaded to storage bucket
Cloud Fucntion downloads file
Converts and merges all base64 strings into image file
Uploads image file to storage bucket
Calls Google Cloud Vision API once file is uploaded

This works, but it has me wondering: how much should a single function do? Most discussions I see regarding single purpose vs. monolithic functions are centered around monolithic functions having logic branches e.g. "if-else". In the above case, this is an example of doing a lot, but, it's conceptually a single unit of "work".

Were I to refactor this into true single purpose functions, I imagine I'd have two functions -- one for downloading and merging images and the other for calling the Vision API. This splits what I consider "image processing" into two sub-units. I have no problem doing this but I'm curious to know whats a good rule-of-thumb for "splitting" FaaS function?

Edit: if anyone is wondering why the image file gets uploaded back into a storage bucket and then the Vision API is called, this due to a limitation of that API where inputs can only be storage bucket URIs and not local files

In my point of view, you can have a future gain separating the function into multiple parts because it will allow to use another combining system/upload/whatever as input to the processing part and another system to process the images later.

My personal rule of thumb for separation is the main concern:

Step 1 is giving the input, it's already somethhing it itself.
Steps 3 and 4 are, basically, take an input, do the work andgive an output. It waits base64 strings as input and output an image file to a bucket, it should be autonomous in its processing
Step 5 is an api call, it waits image as input and "whatever vision API does" as result/output, that's a task in itself.

I did omit step 2 as it's the trigger of step 3 and 4.

The main interest into this separation of duty is the possibility to work with contracts between the functions (mostly bullet 2 and 3): 2 is expected to output images in a bucket, 3 expects to find images in a bucket, you can then replace 2 or 3 with whatever you want as long as this contract is fulfilled.

Now for when to do this split and is it necessary, if you don't expect things to change in a near future and there's no hard limit approaching, like the time to do the whole work is approaching the max execution time, then there's no need to over anticipate problems in my humble opinion, the whole step 3 to 5 can be seen as a single task unit as you said and this make sense.

My take would be to measure the time within the function to see if there's an interest (for parallel processing for exemple) in taking the combine and transform to image to its own unit.

In brief to answer the question title: there's no silver bullet or hard rule for the granularity, it's always a matter of weighting the benefits toward the cost of slicing the process.


Cloud DB operator responsibilities / common tasks When I feed a search engine with "DBA tasks responsibilities" lots of hits like "What does a DBA do all day?" and even official Oracle manual entries.

With modern automation a lot of those tasks don't exist anymore and as a DBaaS provider we sometimes even don't know our customers and his projects.

So what's the tasks of a Cloud DB operator?

I always saw a DBA as someone who fits in between developers and operations when it comes to database management.

On the one hand, they often take care of backups, clustering, replication, actual binary installation, file system management, etc.

On the other, they also take care of relational DB schema, do performance or query optimization, and advise developers on the best way to lay out their application storage and configuration schemas.

In theory, the first job can be done by a system administrator.  The second job can be done by a senior developer or architect.

In practice, it often makes sense to have someone who's well versed in all parts of running a database.

Provisioning the instance is only a small part of what they do.  Having your instance hosted in the cloud doesn't remove the need to have someone manage your schema or optimize performance.  A cloud RDS with default settings likely won't be aware that key_buffer_size value needs to be set to 16M or some of your application's features won't run.


Accessing External REST api From Wthin Kubernetes Cluster This is my first foray into Kubernetes land... I'm still pretty shaky on how things work and still wrapping my head around some of the concepts so please bear with me there.

The application I am deploying needs access to a couple of external third party http rest apis. What I believe I need from reading the docs is a service with an endpoint that points to the external rest apis ip. This is what I have in my helm templates:

service.yaml:

apiVersion: v1
kind: Service
metadata:
  labels:
    run: external_rest_service
  name: external_rest_service
spec:
  ports:
  - port: 443

My endpoint.yaml:

kind: Endpoints
apiVersion: v1
metadata:
 name: external_rest_service
subsets:
 - addresses:
     - ip: https://www.someservice.com/api
   ports:
     - port: 443

This of course doesn't work because ip needs to be an ip address. However, when I do an nslookup of the rest api I get back 3 different ip addresses which I believe may be because of round robin dns. Oddly when I try any of the ip addresses directly via curl I don't get a response. My questions are..

Is this the correct or best practice approach to giving access to an outside resource from within my cluster?
Can I configure (and should I) configure Kubernetes to allow access via domain name instead of ip? If so.. where do I configure this? I'm not seeing it when searching the docs.

If anyone could give me any guidance here I would really appreciate it. Thanks much!

A service in kubernetes is (mostly) used for internal communication. If you want to access an external resource by domain/ip you can just do so. If you have an IP address and you would like to have some sort of domain connected to it, you could you am service with the external name field set to the up address (we use that for database purposes). An endpoint is automatically created for you when you create an service so you don’t nees to bother with that


Deploying a Kubernetes cluster for production on multiple clouds I want to install a highly available kubernetes cluster (multiple master nodes) on a public cloud (AWS, Azure, GCP and maybe others).
I'm looking for a non-vendor specific option to do it.

I'm aware of several options like

Kops
Juju
Other Github projects I found...

I was wondering if anyone has a good automated example of doing this with such tools like Terraform, Ansible or others.

The HA is a must as this if for production use!

At work we are currenly using a multi AZ Kubernetes cluster on AWS and we're using kops along with Terraform (kops generates the Terraform configuration files) to provision the cluster. What is not clear to me is if your intention is to run a single multi-cloud cluster or if you want to run multiple clusters in multiple clouds.

Anyway, our current setup is a multi-master highly-available multi-AZ Kubernetes cluster. I'll try to explain step by step.

The first thing in order to create the cluster is to generate the Terraform configuration with kops (you could directly apply the changes in AWS by directly using kops, but in our case we think it's best to keep the Terraform files versioned in git, to be able to change details about this configuration and inspect them, also). For instance, this could be the command we used:

kops create cluster \
--name=my_new_cluster \
--ssh-public-key=k8s.pub \
--dns-zone=<your-name>.<your-domain> \
--cloud=aws \
--master-size=t2.medium \
--node-size=t2.medium \
--vpc=<vpc-id> \
--zones=us-east-1a,us-east-1b,us-east-1c \
--master-zones=us-east-1a,us-east-1b,us-east-1c \
--out=my_new_cluster \
--target=terraform

This creates the Terraform configurations (in the directory specified by the --out flag) for a Kubernetes cluster which nodes and masters are distributed along 3 Availability Zones (us-east-1a, us-east-1b and us-east-1c). This implies creating:

all necessary subnets, security groups and route tables
IAM roles
AWS Auto Scaling Groups to manage the cluster nodes and masters (it's the magic of all this, they're the ones that maintain the high availability of the cluster by launching extra nodes as traffic increases, and replaces faulty ones)
all EC2 instances and EBS volumes
Route53 DNS records to refer to the cluster API and internal DNS for k8s to communicate with pods.

kops uses kubectl internally to create the cluster and all necessary configurations in Kubernetes.

After that, you could terraform apply the configurations and watch it all go up in AWS. It's quite simple, really, but you have to learn how Terraform works. I've found it very intuitive.

Later on, you may need to edit you cluster. There's a command: kops edit cluster <cluster-name> that let you do that. It's all configurations in  yaml format. I won't get into specifics but after some changes you may need to kops rolling-update <cluster-name> to apply them.

Hope I've been clear.

Regards.


Autoscaling containers using local request counters Somewhere around I got to know about different approaches which were used to scale our webapp which included Scaling using local request counters. Below that they had written the drawbacks of this approach adding that

  Each instance would reach the threshold almost at the same time and
  hence each would demand a new instance, leading to a large number of
  instances even though the number should have increased by one only

I was curious to know if there's a solution to this problem or any workaround ?

The problem can easily be solved using the following components:

On the instances serving your webapp continue to monitor the number of incoming requests – and anything else you see fit.
Publish the number of incoming requests to a monitoring system. If it is not yet implemented, this step will improve your monitoring capacities, and will help you to monitor the load on each hosts as well as host balancing.
From the incoming requests, deduce an estimated required number of webaspp servers needed to serve that work load, as well as the difference between the actual number and the estimated needed number. In the case you describe, it seems that the estimated number is just a scalar function of the total number of incoming requests on a recent period of time. On other systems or after some times, more subtle strategies can be implemented. Monitoring these quantities and the difference could ease the traceability of the auto-scaling strategy, and will monitor its responsivity.
Last implement the auto-scaling itself, at this point, this is really just reading some number from your monitoring system and writing it to your scaling system.


Import tarball as next revision Some background:

I've got an existing build system that creates (among other things) container images.  Due to the nature of their contents, they are suitable for running on practically any containerization toolset one might care to use.

Now I've got some users who want to load them into Docker.  Ok, that works fine, except that each revision of the container image imports separately.

The users would like to take advantage of the space-saving capabilities of Docker layers to deduplicate data between versions.

I could, of course, instantiate the previous image, and then use rsync or similar to update it and then commit it (and that's what I'll do if I have to) but that seems like an awfully clunky workflow.

The question:

Is there some piece of functionality built into Docker that I'm just not finding that would simplify the process of importing updated image tarballs into an existing image's history?  I can find all kinds of resources about pruning and flattening Docker history, but nothing for those of us who manage our image contents via other systems.

This is a known issue with aufs -- see here for context.

Use ADD <tarball_path> and use the overlay driver on the build server.


COPY and ZIP files in Dockerfile Using a COPY statement creates a new image layer, right?

COPY files/foo.zip /tmp/

Now, to save space I could take the ADD statement... for a GZ arhive. But ADD does not support automatic extraction of ZIP files.

So the foo.zip will be dangling around somewhere in a below layer. Just a RUN rm statement does not help.

How do you solve this?

Convert the zip file into a gz file before running docker build, possibly in a wrapper script.

Or even go one step further, and extract the archive first, then use COPY to copy the resulting folder contents.

When you are using archives from the internet on the other hand, ADD http://somewhere/file.gz /data will extract the downloaded file directly into that folder. If you have a problem with zip/gz format there, then use RUN curl -o somewhere/file.gz /tmp/file.gz && tar xzf /tmp/file.gz && rm /tmp/file.gz to only create a single layer without leaving the file behind.


Multiple levels of parallel stages in a Jenkins declarative pipeline I need to define a declarative pipeline with multiple levels of parallel stages as such:

1   Prebuild_action1
2   Prebuild_action2
3.1 Build platform_1
4.1   Test1 platform_1
4.2   Test2 platform_1
4.3   Test3 platform_1
3.2 Build platform_2
3.3 Build platform_3
3.4 Build platform_4

First, 1 should run, then 2 should run, then all of 3.x should run in parallel and when 3.1 is done all 4.x should run in parallel.

It doesn't seem possible for two reasons:
1. There doesn't seem to be any way to have both a stage and a group of parallel stages within a parent stage and it seems that parallel blocks can only be defined at top-level stages so I can't have a parallel block for 3.x and 4.x.

Is there some way to do that I am just not seeing at the moment?

Sure it's possible to have nested parallel stages and it works just fine (I've done it before), but the visualization in the web UI is terrible, even with Blue Ocean.  There was even an official blog post when this feature was added.

This question has already been asked a couple other times on this site as well, you might be interested in these questions and answers:

jenkins pipeline nested parallel
How to build a complex parallel Jenkins pipeline?

It's not entirely clear to me from the wording of your question if it's a duplicate of those questions or if there are significant differences, so I haven't flagged your question as a duplicate.


Why it is recommended to run only one process in a container? In many blog posts, and general opinion, there is a saying that goes "one process per container".

Why does this rule exist?
Why not run ntp, nginx, uwsgi and more processes in a single container that needs to have all processes to work?

blog posts mentioning this rule:

"Single-process-per-container is a recommended design pattern for Docker applications."
"Docker is only for creating single-process or single-service containers."
"better to use one process per container"
"Run a single service as a container"
"One process per container"
"one process per container"

Lets forget the high-level architectural and philosophical arguments for a moment. While there may be some edge cases where multiple functions in a single container may make sense, there are very practical reasons why you may want to consider following "one function per container" as a rule of thumb:

Scaling containers horizontally is much easier if the container is isolated to a single function. Need another apache container? Spin one up somewhere else. However if my apache container also has my DB, cron and other pieces shoehorned in, this complicates things.
Having a single function per container allows the container to be easily re-used for other projects or purposes.
It also makes it more portable and predictable for devs to pull down a component from production to troubleshoot locally rather than an entire application environment.
Patching/upgrades (both the OS and the application) can be done in a more isolated and controlled manner. Juggling multiple bits-and-bobs in your container not only makes for larger images, but also ties these components together. Why have to shut down application X and Y just to upgrade Z?

Above also holds true for code deployments and rollbacks.

Splitting functions out to multiple containers allows more flexibility from a security and isolation perspective. You may want (or require) services to be isolated on the network level -- either physically or within overlay networks -- to maintain a strong security posture or comply with things like PCI.
Other more minor factors such as dealing with stdout/stderr and sending logs to the container log, keeping containers as ephemeral as possible etc.

Note that I'm saying function, not process. That language is outdated. The official docker documentation has moved away from saying "one process" to instead recommending "one concern" per container.


Kubernetes Deployments & Rollbacks At the moment I'm performing Kubernetes deployments by applying deployment.yaml then updating the container/pod image versions with kubectl set-image as outlined in the docs. I'm doing this using Jenkins.

If I understand correctly, each time I apply kubectl set-image it updates the deployment in situ creating a new ReplicaSet meaning that I don't need to create a new deployment.yaml for each version bump.

Is this best practice or should I be creating a new deployment.yaml every time we bump version?

My next question concerns rollbacks, if I run kubectl rollout history deployment/name, I see three revisions but no 'cause'. I think this is because I've not specified --record on the initial deployment, and does that record each time we do a set-version too?

I think it might be a good idea to update deployment.yaml for each version/release and commit to git so that later, any other person may follow through and even revert back to an earlier release/version.


Any site to host my little utility script? I have a small node js script running in my aws ec2. It is just one file. If I hit the server with a query param, it will do some utility job (like hashing) and return the result in html.
Since its a small script I wondered if there is any site that can host small code for free. I can create a path/subdomain for my script and upload my script. so whenever I hit the my url the should just feed the url to my script and return whatevr the script returns as http response.
Is there any such site there?
If node js is too much, I can make it as a shell script too.

Have you considered running this on AWS Lambda. It will probably forever free under free tier. There may be a couple of cents cost on API Gateway.
Otherwise you can rent outdated servers for cents per month,  but I am unsure what the best search term is for that.
Finally,  email addresses are free to generate and you can invest the time to set up a fresh AWS account once per year and run on free tier.


How to close a branch by default after a pull request has been merged in Bitbucket? By default a branch will remain in Bitbucket when a Pull Request (PR) has been merged. How to ensure that a branch will be removed after a PR has been removed?

When the option is enabled then the branch will be removed after the merge of a PR, but how to ensure that it is clicked by default to prevent that creators of the PR forget to click it and the branch remains in bitbucket?

What I really want is to add a comment to the accepted answer, but I don't have enough reputation to do so. So I'll note it here. I've closed BSERV-10344 because it's in the wrong tracker. This question is about Bitbucket Cloud (bitbucket.org), not Bitbucket Server (the behind-the-firewall version). The correct issue tracker for the feature request is at https://bitbucket.org/site/master/issues.

Also, re: "I'm not sure why they use different language for that", it's because Bitbucket Cloud supports Mercurial as well as Git. In Mercurial it's not possible to delete a named branch; they can only be closed. Since its support for Mercurial predates its support for Git, the terminology used is to "close" the branch.


How do Django deployments happen on Servers? I am new to Django six months ago and I learned how to deploy the Django projects to EC2 instances.

Basically 1st time when the Django project is deployed to EC2, the instance will be configured with httpd.conf, wsgi, change permissions on files and folders and other stuff and the project will be cloned to the EC2 instance and server is restarted.

My question is: how do they do future deployments? They in this context is anyone who deploys Django on EC2 instances.

Do they login to EC2 instances and manually clone the repository from VCS site and restart the server?

Do they have any other automated mechanism to pull the code, ensure permissions and restarting the apache server etc.

How is it done basically every time they go for a release?

Probably, you want need to go through something like Ansible first. Nothing is done manually these days, not even launching of EC2 instances or creating a VPC is manual and if it is, it needs to be changed immediately. You may also go through Terraform. You also need to understand CI/CD flow. So when any changes are pushed to git, a CI mechanism will execute which can include build, compile, unit test execution, integration test execution, code coverage reports etc which are all automated. Deployment can either be automated if CI is successful or on click of a button. Ansible can take care of the configuration changes which needs to be deployed including the application code changes. In fact, if you are in AWS, why don't you go for docker and deploy app in Docker using benefits of Amazon ECS. A Terraform code can do zero downtime deployments for you.
This is not specific to Django. It is used for any tech stack.


What's the equivalent of `heroku container:release web` without using heroku-cli? I have a bitbucket pipeline that almost working:

image: atlassian/default-image:2

pipelines:
  default:
    - step:
        services:
          - docker
        script:
          #Build the image
          - docker build -t $IMAGE_NAME ./backend
          #Login to heroku's docker registry with an API token
          - docker login --username=_ --password $HEROKU_TOKEN registry.heroku.com

          #Tag and push our built image to the heroku docker registry
          - docker tag $IMAGE_NAME registry.heroku.com/$HEROKU_APPLICATION_NAME/web
          - docker push registry.heroku.com/$HEROKU_APPLICATION_NAME/web

The final step is - I would run something like heroku container:release web  -a=$HEROKU_APPLICATION_NAME

How can I do that without actually having the heroku-cli (ie. from the bitbucket pipeline).

You can install the Heroku CLI via npm - which might be the simplest.

Note that your Heroku API key has to have the env var name HEROKU_API_KEY for the Heroku CLI to accept it as an auth token (ie. to avoid having to do heroku login).

          - npm install -g heroku

          # build the Docker image (this will use the Dockerfile in the root of the repo)
          - docker build -t $HEROKU_APPLICATION_NAME ./backend
          # authenticate with the Docker Hub registry
          - docker login --username=_ --password $HEROKU_API_KEY registry.heroku.com

          - docker tag $HEROKU_APPLICATION_NAME registry.heroku.com/$HEROKU_APPLICATION_NAME/web
          - docker push registry.heroku.com/$HEROKU_APPLICATION_NAME/web
          - heroku container:release web -a=$HEROKU_APPLICATION_NAME


What is the name of Jenkins plugin for GitHub plugin configuration? We need below plugin in Jenkins:

Currently I have installed below list of plugins:

git:latest
git-client:latest
git-server:latest
github:latest
github-api:latest
github-branch-source:latest

Am using Jenkins 2.190.2

I could not find GitHub plugin configuration in Jenkins after navigating Manage Jenkins -> Configure System

What is the name of the GitHub plugin that needs to be added in plugin list to install using /usr/local/bin/install-plugins.sh?

The plugin that you are looking for is: https://github.com/jenkinsci/github-plugin.

You need to go in Manage Jenkins > Global Configuration to find the GitHub plugin configuration (according the documentation).


Specify default arguments for Ansible playbook When I create playbooks I often add a comments section at the top on how to run the Ansible playbook. With more options becoming available in Ansible, the list of command-line arguments also seems to grow. It made me curious to see if there is a way to specify defaults for these arguments in the playbook.

For example my playbook needs the following arguments:

the hosts file: -i hosts
the password for become: -K
the password for the vault: --ask-vault-pass
the name of the playbook: myplaybook.yml

It would be easier if I could just run the following command (especially for co-workers):
ansible-playbook myplaybook.yml

And specify in the playbook, that by default it should look for a hosts inventory file and ask for sudo + vault passwords. Of course I could create a script and wrap the playbook command, but that adds another layer on top of it.

I guess I'm looking for adding something like this to my playbook:

vars:
  inventory_file: hosts
  ask_become_pass: true
  ask_vault_pass: true

Is that possible?

That's what the configuration file is for. Create an ansible.cfg in the directory from where you run ansible, like so:

[defaults]
inventory = hosts
ask_vault_pass = True

[privilege_escalation]
become_ask_pass = True

See also http://docs.ansible.com/ansible/latest/reference_appendices/config.html

The ansible.cfg in the working directory precedes /etc/ansible/ansible.cfg. The full search order is described on the page linked above. Command line options you pass on invocation override all configuration files.


What are Pros and Cons of being a CIO? What I have heard of Chiefs is the following:

Pros:

Bigger influence of decisions that will be made

Cons:

Less time to be technical. Most of the chiefs told me that they only can spend a maximum of 10% of their time to be technical.

What are other pros and cons of being one of the Chiefs or are some chiefs, e.g. CTO, CIO, COO spending more time to fix technical problems by themselves?

A CIO is part of the company leadership. His primary duties is to make policies, create organization (i.e., structure the company, at least the part that reports to him), make strategic decisions etc. In a large company, many technical people report directly or indirectly to the CIO; if there are technical problems to solve, he is supposed to hire people to solve those problems, or - more likely -
have his direct reports hire those people.

I would be very wary if a CIO starts fixing technical problems himself. This probably would mean that he has trouble delegating, or trusting his employees.

There may be a phase in a very small company (like 5-10) where you might have some kind of senior technical person who starts to grow into the CIO role. But that should certainly be a path that develops itself (often it is quite obvious who is a good fit for that role and who isn't), and nothing where you start pondering whether you want to become CIO or not out of the blue.


Ansible can't recursively delete a directory So, I am trying to recursively delete a directory with all files/folders inside.
I tried:

  - name: Cleaning up
    file:
      state: absent
      path: /tmp/myfolder/

But the directory did not get deleted. Is there any force/recursive parameter I can add? What am I missing?

You may find the following format to be helpful:

- name: Recursively change ownership of a directory
file:
  path: /etc/foo
  state: directory
  recurse: yes
  owner: foo
  group: foo