When stopping a container one way or another, like by Ctrl+C or docker stop, Docker sends SIGTERM to the process by default. If the first process (PID = 1) on the container is not a proper init process, the termination may take a long time to be done. It's because processes running as PID 1 are treated differently than usual ones.
In Linux, a process running as PID 1 ignores any signal unless the process implements signal handlers on its own.
In RSpec, some matchers can take another matcher as an argument. It is sometimes useful for writing an expectation for a collection. Let's say we want to test that an array contains a string that includes a particular text. We can do that by combining two matchers: include and match as follows.
expect(an_array).to include(match(/Lorem/)) # Of course we also could do: # expect(an_array.grep(/Lorem/)).not_to be_empty # or # expect(an_array).to be_any {|item| /Lorem/ === item } I think that in this case, the expectation with include and match is much more concise than the commented-out alternative ways above.
Sometimes I want to create a tiny one-off script that intended to run on a sandbox environment like a Docker container and needs only one file. Most of the time, I also need test frameworks to do some refactoring. It can be done with bundler/inline and rspec/autorun.
require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'rspec' end def doit 'return a string' end require 'rspec/autorun' RSpec.describe '#doit' do example do expect(doit).to be_a(String) end end Usually, Bundler reads the dependencies from Gemfile.
Today I learned that in docker-compose.yml, a variable interpolation with a default can be expressed as ${VAR1:-default value} like shell-style parameter expansion. With parameter expansion, you can do more than setting a default value such as modifying the parameter. However, the supported features in docker-compose.yml are limited to two of them: to set a default variable or to make the parameter mandatory.
Let's define VAR_ALPHA with a default value for the example service.
While I was playing with act the other day, I found a tool called kind (Kubernetes in Docker) in that repository. With kind, Kubernetes clusters can easily be created in a Docker container.
According to the official document, being an alternative to Docker Compose out of scope for kind. That said, the home page also suggests kind may be used for “local development”.
kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.
