ストレングス・ファインダーをやってみて自分の特性が明確になったお話

先にまとめ

主に自分向けの内容です

  • ストレングス・ファインダーは、得意を伸ばすために、自分の資質と伸ばし方を知るメソッド
  • 自分の資質のTOP5は、「適応性」「回復志向」「調和性」「収集心」「原点思考」だった
  • 自分の方向性が見えたので、今後の行動の指針にすべく「できないこと」「積極的にやること」「強みを伸ばすためにやること」を作ってみた
  • 自己評価が低い人は一度やってみると良いと思った

ストレングス・ファインダーとは

その人の精神的な特性(「資質」と呼ぶ。全32種類)を見える化して、それを伸ばして「強み」にするメソッド

  • 人は苦手をなくすより得意を伸ばしたほうが得るものが多いよね。という思想で作られている
  • 古本を買わないように注意!! 本についてるアクティベーションコードで、資質をチェックするwebテストを受けて、それを元に話を進めるため

自分はどうだったの?

自分の資質のTOP5は、「適応性」「回復志向」「調和性」「収集心」「原点思考」だった

それぞれ、こんな特性だと理解

適応性

現在に重きを置き、柔軟に現在の状況に対処する資質。 弱点は厳密な計画性や手順。計画をたてるときは別の資質を持つ人に助けてもらう。 短期決戦の繰り返しの時に最も生産的になれる。

回復志向

問題の解決が得意。チームやプロジェクトの問題を特定し、本来あるべき状態に回復させる。 自分の問題に厳しく向き合いすぎるので、改善可能な具体的な課題(スキル不足など)に落とし込むと良い。自分が得た経験を共有し、問題の予防に落とし込めればより価値を提供できる存在になれる

調和性

同意点を求め、違いを受け入れる資質。違う視点を持つ人々を交流することができるタイプ。その人達を招き入れたり、頼ることでより多くのものを得ることができるはず。また、ファシリテーター向き。逆に日常的に人と対立する仕事や人が対立している環境は避けるべき

収集心

コレクター。何のためではなく、収集する性質。毎日新しいものごとを収集する必要がある仕事が向いている。意識的に収集する時間を作ると良い。集めたものを役立つようにアウトプットするのが苦手なので、意識して集めたものに価値を見出してくれるグループにアウトプットしていくこと

原点思考

歴史的経緯、はじめの意図を知ることで今の問題を解決できると信じている。ものごとの背景に関する深い理解を示す。その人のこれまでを知っているのでより深く交流ができる。逆に初対面や新しい状況が苦手。過去の事例から、成功の為に切り捨てるべきことと、保持するものが分かるはず

資質を見せられて感じたこと

  • 自分が今まで他者に言われてきたことが大半だったので、納得感は高かった
  • 意思決定や未来を想定するというのがニガテというのは、ちょうどマネジメントに挫折した所だったので納得
  • 相反する資質については、その資質を持つ他者とチームを組むことで生産性を上げれば良い。とも本に書かれているし、せっかく調和性が高いので人に頼ることを意識したい。
  • 調和性は裏目に出ると他者の要望に答えている内に自分の長期的な利益を損なうらしい。自覚があるので、どこまで許容するか自分の中で線を引きたい
  • 長期的な計画を短期決戦に落とし込む工夫をする必要がある。OKRのKeyActionをなるべく細かく具体的にするとか、(当たり前だけれど)スプリントバックログで付けられた優先度で作業するとか、個人的なテクニックとして、ポモドーロ・テクニックとか、TDDとか。

自分の方向性が見えたので、今後の行動の指針にすべく「できないこと」「積極的にやること」「強みを伸ばすためにやること」を作ってみた

それを自覚して他者にも明示することで、より良いアウトプットができるはず

これは本に書かれていることではなく、自分をより俯瞰するために勝手にやってみたこと

できないこと

  • 長期的な計画を立てたり、意思決定をするときは、助けが必要
  • 常に厳密な行動が定められている仕事はミスをする可能性が高い
  • 対立が発生している環境に居続けることはできない

積極的にやること

  • 発生したトラブルや障害について率先して対応する
  • ミーティング等で積極的にファシリテーターを務める

強みを伸ばすためにやること

  • 人に頼る。1日1回だれかにアドバイスや助けを求める
  • トラブルを解決するためのスキルを身につける。月に1つテーマを決めて、現状の仕事で足りていないスキルを身につける
  • 長期的な計画を短期決戦に落とし込む。大きいタスクは切り分けて、自分の中で締め切りを設ける

最後に感想

自分の苦手には目がいくが、得意は自覚できていなかったので、やれて良かった。自己評価が低い人こそやると良いと思った

ECSのawsvpcネットワークモードおぼえがき

awsvpcネットワークモードとは?

taskにENIを紐付けるネットワークモード

ENIとは?

Elastic Network Interface

仮想ネットワークカードを表す VPC 内の論理ネットワーキングコンポーネントです インスタンスにネットワークインターフェイスをアタッチすると、プライベート IP アドレス、Elastic IP アドレス、セキュリティグループを指定できます。

docs.aws.amazon.com

ENIが使えると何が得なの?

ENIを使えば、taskが通信する時にhostのネットワークインターフェースを意識する必要が無くなる

  • ENIを使わない場合 hostマシンのネットワークインターフェースを使う必要がある。その為、複数のtaskが動作するhostのセキュリティは、最大公約数的なものになってしまう

その他の特徴

同じタスクに属するコンテナが、localhost インターフェイス経由で通信できるようになります。 ある時点でタスクに関連付けられている Elastic Network Interface は 1 つだけです。

docs.aws.amazon.com

AWS Fargateの場合、awsvpcネットワークモードが必須

ホストマシンが存在しないので、独自にネットワークインターフェースを持つ必要があるため

AWS Fargateでtaskを動作させるのに必要な設定の記録

task definition

以下はインスタンスのcpuinfoとメモリの情報をチェックするtaskのdefinition

{
    "family": "get_fargate_cpu_info",
    "containerDefinitions": [
        {
            "name": "get_fargate_cpu_info",
            "image": "#{AWS_ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com/get_fargate_cpu_info",
            "entryPoint": ["bash", "-c", "cat /proc/cpuinfo && free -h"],
            "essential": true,
            "memoryReservation": 512,
            "logConfiguration": {
               "logDriver": "awslogs",
               "options": {
                 "awslogs-group": "get-fargate-cpu-info",
                 "awslogs-region": "us-east-1",
                 "awslogs-stream-prefix": "cpuinfo"
               }
            }
        }
    ],
    "requiresCompatibilities": ["FARGATE"],
    "networkMode": "awsvpc",
    "cpu": "256",
    "memory": "512",
    "executionRoleArn": "arn:aws:iam::#{AWS_ACCOUNT_ID}:role/ecsTaskExecutionRole"
}

aws ecs run-task

{
  "taskDefinition": "get_fargate_cpu_info",
  "cluster": "get-fargate-cpu-info",
  "networkConfiguration": {
    "awsvpcConfiguration": {
      "subnets": ["subnet-********"],
      "securityGroups": ["sg-********"],
      "assignPublicIp": "ENABLED"
    }
  },
  "launchType": "FARGATE"
}
  • launchType : FARGATE 必須
  • networkConfiguration : awsvpcConfiguration の定義が必要
    • assignPublicIp: ENABLED にして、外に出れるようにしないと、ECRからコンテナを取りにいけない

参考

AWSのドキュメントに添ってECSを動かしてみた

この2つを参考に、ECSを動かしてみた

docs.aws.amazon.com

docs.aws.amazon.com

ゴール

Hello World と書かれた index.html を持つ apache サーバをECSで動作させて、ブラウザで動作確認する

手順

  1. DockerImageを作る
  2. DockerImageをECRに登録する
  3. Task DefinitionをECSに登録する
  4. Taskを実行するClusterを作成する
  5. Cluster上でTaskを起動する

DockerImageを作る

以下の Dockerfile を作成する

FROM ubuntu:12.04

# Install dependencies
RUN apt-get update -y
RUN apt-get install -y apache2

# Install apache and write hello world message
RUN echo "Hello World!" > /var/www/index.html

# Configure apache
RUN a2enmod rewrite
RUN chown -R www-data:www-data /var/www
ENV APACHE_RUN_USER www-data
ENV APACHE_RUN_GROUP www-data
ENV APACHE_LOG_DIR /var/log/apache2

EXPOSE 80

CMD ["/usr/sbin/apache2", "-D",  "FOREGROUND"]

Imageを作成

$ docker build -t hello-world .

動作確認

$ docker run -p 80:80 hello-world

DockerImageをECRに登録する

ECSから使用するImageを参照できるように、レジストリに登録する必要がある

リポジトリの作成

$ aws ecr create-repository --repository-name hello-world

戻り値

{
    "repository": {
        "repositoryUri": "${AWS_ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com/hello-world",
        "repositoryName": "hello-world",
        "createdAt": 1521868901.0,
        "repositoryArn": "arn:aws:ecr:us-east-1:${AWS_ACCOUNT_ID}:repository/hello-world",
        "registryId": "${AWS_ACCOUNT_ID}"
    }
}

Imageにタグをつける

$ docker tag hello-world ${AWS_ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com/hello-world

タグとは

  • Gitのタグと近い概念
  • Imageに複数のタグが登録できる
  • 7.7 とか 7.7.4-alpine とかバージョンやディストリビューション毎にタグを付けて管理することが多い

上記のコマンドの場合、タグ名を指定していないので、latest タグが付く

タグ名を付けたい場合は、image名の後ろに :TAGNAME を付ける

ECRにImageをpushする

dockerコマンドからECRにログインするためのコマンドを生成させる

$ aws ecr get-login --no-include-email

標準出力に出てきたコマンドを実行して、ECRにログインする

  • ******** はパスワード
$ docker login -u AWS -p ******** https://${AWS_ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com

ECRにImageをpushする

$ docker push ${AWS_ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com/hello-world

Task DefinitionをECSに登録する

Task Definitionを作成

{
    "family": "hello-world",
    "containerDefinitions": [
        {
            "name": "hello-world",
            "image": "${AWS_ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com/hello-world",
            "cpu": 10,
            "memory": 500,
            "portMappings": [
                {
                    "containerPort": 80,
                    "hostPort": 80
                }
            ],
            "entryPoint": [
                "/usr/sbin/apache2",
                "-D",
                "FOREGROUND"
            ],
            "essential": true
        }
    ]
}

Task DefinitionをECSに登録する

$ aws ecs register-task-definition --cli-input-json file://hello-world-task-def.json

Taskを実行するClusterを作成する

AWSコンソールから作ると色々必要なものを自動で作ってくれるらしい

f:id:kasei_san:20180325174555p:plain

AWS Fargate でも良いが、まずはEC2インスタンスを使ったクラスタを理解したいので「EC2 Linux+ネットワーキング」を選択

f:id:kasei_san:20180325174719p:plain

必要な項目を入力後、Cluster、VPC、サブネット、IAMポリシー、オートスケーリンググループ等、必要なものが自動的に作成された

  • CloudFormationは、AWSのリソースの集まり(EC2とかVPCとか)を1つの集まり(スタック)として捉えて、jsonで管理。必要に応じて同じものを簡単に複製できる仕組み

f:id:kasei_san:20180325175537p:plain

Cluster上でTaskを起動する

aws ecs run-task でタスクを起動できる

$ aws ecs run-task --task-definition hello-world --cluster test

AWSコンソールでTaskが起動していることを確認

f:id:kasei_san:20180325180307p:plain

インスタンスのURLにアクセスすると、Hello World が表示されている!

f:id:kasei_san:20180325180427p:plain

ひとまずここまで

今後理解したいこと

  • Service(今回はタスクしか使わなかった)
  • オートスケーリンググループ
  • ロードバランシング
    • 複数のコンテナで同じタスクを起動した場合、どのようにロードバランシングされるのか?
  • AWS Fargate

Amazon ECS 覚え書き

Amazon ECSとは

Amazon Elastic Container Service (Amazon ECS)

Docker コンテナをサポートする拡張性とパフォーマンスに優れたコンテナオーケストレーションサービスです

  • (最近乱立しがちでK8Sに統合が向かうのかどうなのかわからない)コンテナオーケストレーションサービスの一つ。
  • API/web画面から、EC2クラスタ上にDockerコンテナを起動/管理できる
  • AWS Fargate を使えば、インフラ(EC2)のことを考えずにコンテナを管理できる

用語

Task

1つ以上の協調して動作するコンテナ群

  • Dockerでは、1コンテナ1サービスを推奨しているので、何かを実現しようとすると大体複数のコンテナが必要になってくる

Task Definition

Taskの設定

  • docker-composeとかと近い概念

Service

  • タスクで必要なコンテナを指定した数だけ起動/維持してくれる
  • なんらかの理由でタスクが死んでも、サービスは必要数のタスクを維持する
  • あとELBとの連携とか

Cluster

Taskを実行するEC2の集合

  • 各EC2インスタンスには、ecs-agent なるサービスが起動していて、ECSとやり取りしている

参考

Amazon EC2 Container Service(ECS)のデータモデルについて整理した | Developers.IO

ruby:2.3.6-alpine3.4 に、postgresql-dev 9.6系をインストールしようとしたら conflict が発生した話

現象

alpine3.4 だと、postgresql-dev や client が 9.5 系

9.6 系を入れたくて、Dockerfileで /etc/apk/repositories を加工して、alpine3.5系のパッケージを入れるように変更した

/etc/apk/repositories

  http://dl-cdn.alpinelinux.org/alpine/v3.5/main
  http://dl-cdn.alpinelinux.org/alpine/v3.5/community

するとこんなエラーが

ERROR: unsatisfiable constraints:
  openssl-dev-1.0.2n-r0:
    conflicts: 
               libressl-dev-2.5.5-r0[pc:libcrypto=1.0.2n]
               libressl-dev-2.5.5-r0[pc:libssl=1.0.2n]
               libressl-dev-2.5.5-r0[pc:openssl=1.0.2n]
    satisfies: .ruby-rundeps-0[openssl-dev]
  libressl-dev-2.5.5-r0:
    conflicts: 
               openssl-dev-1.0.2n-r0[pc:libcrypto=2.5.5]
               openssl-dev-1.0.2n-r0[pc:libssl=2.5.5]
               openssl-dev-1.0.2n-r0[pc:openssl=2.5.5]
    satisfies: 
               postgresql-dev-9.6.8-r0[libressl-dev]
  build-dependencies-0:
    masked in: cache
    satisfies: world[build-dependencies]

ruby は OpenSSL を postgresql-dev は LibreSSL を使っているため、 複数のSSLLibraryが混在してconflictが発生している様子

原因

alpine linux が 3.5 になった時に、OpenSSL から LibreSSL に切り替わったのが原因 そのため、alpine3.4系に、3.5系のSSLを使うライブラリを入れるとConflictが発生する

alpinelinux.org

日本語の記事

gihyo.jp

対策

諦めた

springの子プロセスが `BUNDLE_APP_CONFIG` を無視するバグがある

現象

docker-compose を使って、run bin/rake を実行した時に、Could not find rake が発生

(ローカル環境では正しく動作する)

$ docker-compose exec web bundle exec bin/rake --version
Could not find rake-12.3.0 in any of the sources
Run `bundle install` to install missing gems.

発生したバージョン

ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux-musl]
rake, version 12.3.0
Rails 5.1.4
gem 2.7.6
Bundler version 1.16.1

何故発生するのか?

ruby の docker image では 環境変数 BUNDLE_APP_CONFIG を設定している

  • 環境変数 BUNDLE_APP_CONFIG は、bundler の設定ファイルの場所を特定する環境変数
  • 未設定の場合は、./.bundle

以下のissueによると、springの子プロセスが bundler/setup を参照するときに、bundler が正しいconfigの場所を参照しなくなるとのこと

github.com

対策

  1. issue にあるように BUNDLE_APP_CONFIG を使わない
  2. springを使わない