Posted at

concourseのTIPSメモ

More than 1 year has passed since last update.

concourseは設定をyamlで記述出来たり、Cloud Foundryのような大規模なOSSで利用されているように、 元々jenkinsで運用していたけれどツライ部分があったので作られたので非常にシンプルな作りになっています。

しかしまだまだJenkinsと比べると利用者が多くないので、以下のようなポイントでTIPSをまとめて行きます。


  • 自分や身近でハマったポイント

  • その他の人がSlack等でハマっているやり取りをしていたポイント


concourseのJOBが動いたコンテナに入るfly intercept(fly hijack)がつながらない時

fly interceptをしても上手くコンテナに入れないときがある。

以下のようにコンテナ内部のシェルでなくこちら側のシェルに戻ってしまうケース

$ fly -t moog intercept -j test/test-pipeline

1: build #1, step: test-task, type: check
2: build #1, step: test-task, type: task
choose a container: 2
$

Concourseの公式Slackのチャンネルでやり取りがされていた。

thinkt [11:35 PM] 

Hi all, has anyone had `intercept` fail to intercept a container? How do you usually find out what’s happening?

[11:36]
```fly -t tutorial intercept -j docker-compose-spike/docker-compose
1: build #12, step: docker-compose, type: check
2: build #12, step: docker-compose, type: task
choose a container: 2
~/p/c/concourse ❯❯❯```

[11:36]
This is what I’m getting - it just returns back to the shell prompt after choosing a container to intercept

----- May 2nd -----
joshzarrabi
[12:45 AM]
@thinkt run 'fly intercept -j <pipeline/job> /bin/sh'

[12:46]
@thinkt you are probably intercepting into a container without bash, which is what we default to, so you have to tell it to run sh instead

thinkt [12:47 AM]
that works, thanks @joshzarrabi

原因としては、非常にシンプルでdocker run等で/bin/bashを指定したものの


利用しているDocker Imageには/bin/bashがなく/bin/shのみしか無いケースと同じ理由

fly interceptのデフォルトが/bin/bash指定と同じになるため以下のように実行すると解決する

$ fly -t moog intercept -j test/test-pipeline /bin/sh

1: build #1, step: test-task, type: check
2: build #1, step: test-task, type: task
choose a container: 2
/tmp/build/63b66672 #