14
results
for docker
-
日本IBMでk8sの入門イベントがあるとのことで参加してきた。 開催場所 日本IBM箱崎事業所 Docker/kubernetes入門 (戸倉彩 (とくあや) @絶賛執筆中(@ayatokura)さん | Twitter) IBMデベロッパーアドボケイト 元MSのテクニカルエバンジェリスト クラウドネイティブ 市場をリードする、スピード(開発、運用、デプロイ、Time to Marcket) Key Technology マイクロサービス コンテナ Docker Kubernetes マイクロサービス -> マーティン・ファウラーの2014年3月のブログエントリー Microservices マイクロサービス(用途や目的別) スケールアウトしやすい チームの連携はAPIで定義 課題 時間とともに複雑化していく 有名な事例 Pokemon Go : Google Cloud Platform Japan 公式ブログ: Pokémon GO の爆発的ヒットを支える Google Cloud GitHub Case Studies – Kubernetes 物理理的なコンテナでは港湾荷役の人手ボトルネックだった コンテナを採用することでパイプラインが自動化されてボトルネックが解消する Docker リソース効率が良い ポータビリティ 起動が速い コンテナのツラミ 監視 管理 そこでk8s スケールアウト 負荷分散 ロールアップデート ポリシーベースでの可用性 Home – DevOps.
-
Docker Meetup Tokyo #26 Docker Meetup Tokyo #26 に参加してきたのでそのメモ。 Stress Test with LOCUST on k8s(株式会社プレイド Masahiro Yamauchi(@algas)さん | Twitter) k8s使った事ある人 8割くらい 負荷テストの難しさ(ネットワークやスペックがボトルネックになる) LOCUST pythonベース k8sでLOCUST環境を構築(GKE) worker台数を自由に増減させられる DDoSとみなされないように 10000ユーザーくらいでテストした KubeCon China参加報告(ゼットラボ株式会社 Kazuki Suda / すぱぶら(@superbrothers)さん | Twitter) ゼットラボ(yahoo 100%子会社) Harbor,Dragonfly KubeConの中国開催は初(アジア圏で初めて) 上海は綺麗、ご飯美味しい、アメリカはご飯が微妙だった ファーウェイクラウドでk8sのマネージドを提供,企業3番目にコントリビュートしてる k8s靴下販売してた Harbor:イメージレジストリ TiKV:分散トランザクション Dragonfly:P2Pコンテナイメージ配信(Alibaba) CNCFサーベイ2018では58%で本番でk8sを本番運用している k8s is boring(本番で心配なく運用できている) ブロックチェーンとかマシンラーニングとかIoTで使われはじめてる Harbor(会場内では使っている人はいない) Dragonfly(本番で使っている人はいない) etcdの初期の開発をしていた人がつくっている OSS Javaで書かれている(Goで書き換えるらしい) k8sでベアメタルを管理したりするセッションとかもあった k8sでk8sを管理する https://speakerdeck.com/superbrothers/kubecon-plus-cloudnativecon-china-2018-recap いま話題のいろいろなコンテナランタイムを比較してみた (Comparison of several container runtimes)(NTT Kohei Tokunaga(@TokunagaKohei)さん | Twitter) [高レイヤー]containerd,cri-o,rkt [低レイヤー]runc,gVisor,Nabla Containers,Kata Containers critoolsを使ってpodの作成から破棄までを測定 rkt -> 最近は盛り上がりがなくなってきてる containerd,cri-oはパフォーマンスに差は殆ど無い rktはパフォーマンスがあまり良くない runcはLinuxの機能フル活用してセキュリティを担保している gVisorはGoogleが発表 アプリはgoroutineで実行 runnc(Nabla Container)はIBMが開発 Kata-runtime(Kata Containers)はOpenStack Foundationのプロジェクト PodとしてLinuxのVMを作成して中のコンテナが起動する Kata ContainerはPodの起動が他のランタイムより遅い 一番性能が良かったのは Containerd + runnc 一番性能が悪かったのは rkt + coreos Docker Swarm-mode(ZOZO inductor(▼・Å・▼)(@inductor)さん | Twitter) いまはSwarm Modeになってる swarmpit k8sはコミュニティが強い クラウドプロバイダが躍起になって対応している k8sの理解は難しい 分散基盤とかいらないレベルの小さなWebアプリの環境に入れるほどの規模じゃない 業務コストにみあうものは? Docker Swarmを使うのも一つ Swarmのデモ https://speakerdeck.
-
概要 現在、会社の開発環境でdocker for mac/windowsを採用している。 開発環境なので、都度コンテナにログインはせずに、docker-composeを使用して、ローカルのGithubリポジトリをマウントすることで、開発環境としている。 問題 フロントエンドのコンテナでyarn buildすると明らかにローカルで実施したときよりも遅い。 マウントしているから仕方がないとはいえ、体感でも倍以上のビルド時間がかかっているように思われた。 対策 色々調べていたら、先日弊社の開発ランチにも来られたコネヒトさんのブログがあった。 開発環境改善としてDockerを導入した話 Volumeにcachedオプションを採用しているとのことだった。 volumeオプション(consistent/cached/delegated) https://docs.docker.com/docker-for-mac/osxfs-caching/#performance-implications-of-host-container-file-system-consistency デフォルトはホストとコンテナの変更点の差分を小さくするためにconsisutentになっているようだ。 cachedはホストの更新がコンテナへ反映される時間の遅延を許容し、delegatedはコンテナの更新をホストに反映されるまでの時間の遅延を許容するらしい。 cachedとdelegatedのどちらを使用すべきか判断が難しいが、cachedを設定している記事が多いのでまずはcahedで様子見してみることにした。 コード コードとしては、docker runのvolumeにcachedを付与するか、docker-composeに付与する。 docker run docker run -dti -v $(pwd):/var/www/:cached centos bash docker-compose volume: - ../../dir1:/var/www/repos:cached 計測結果 BEFORE root@78d7d3c19461:/var/www/repos# time yarn build yarn run v1.9.4 (node:100) ExperimentalWarning: The fs.promises API is experimental $ node scripts/build.js (node:111) ExperimentalWarning: The fs.promises API is experimental Creating an optimized production build... Starting type checking and linting service.docker Created
29 Oct 2018 -
概要 AmazonECR(Amazon Elastic Container Registry)の使い方メモ。 公式ドキュメント パブリックなイメージだったら、hub.docker.comで良いと思うが、会社で使うイメージはプライベートなリポジトリが必要である。 Dockerが公式に出しているregistryコンテナを使えば、プライベートリポジトリを管理できるようだが、AWSではECRというマネージドのサービスがある。 今回はECRにリポジトリを作成して、イメージをPushする所まで。 リポジトリ作成 まず、AWSでECSの画面を表示し、リポジトリを選択。 次にリポジトリを作成を選択。 任意のリポジトリ名を設定する。role単位(example-app,example-phpなど)で作成。 これで作成完了。超簡単。画面下にイメージプッシュの手順が記載されている。 イメージのプッシュ まずはECRへログインする。もちろん、自分のアカウントがECRにアクセスできる権限でないと駄目。 $(aws ecr --profile ここにプロファイル名 get-login --no-include-email --region ap-northeast-1) Login Succeeded 手順だとprofile名抜けているので、初めてだとアクセスできなくて詰まるかもしれない。 自分で作成したDockerfileをビルドする。 docker build -t inamuu-test01 . Sending build context to Docker daemon 7.68kB Step 1/5 : From nginx:latest ---> 71c43202b8ac Step 2/5 : MAINTAINER inamuu ---> Using cache ---> 6ad1e68f5596 Step 3/5 : COPY ./var/www/html /var/www/html ---> Using cache ---> 8fa5219e2db1 Step 4/5 : COPY .docker Created
4 Sep 2018 -
弊社では開発環境にDockerを使用している。 開発環境はインフラ含め、アプリケーション開発を手元で行えるようにコンテナ化されている。 イメージはAmazonECRにあるので、開発する人は、ECRへログインしてイメージを取ってくることで、最新のイメージが使用できるようになっている。 今日、会社の開発者の方からECRにログインできないという相談を受けた。 ECRにログインする際は下記ワンライナーでログインするのだけど、それでエラーが出てしまう。 $(aws ecr --profile XXXXXXX get-login --no-include-email --region XXXXXXXXXX) 通常、このあとに、 Login Success! みたいなのが表示されるのだが、今回はこんなエラーが表示されていた。 Error saving credentials: error storing credentials - err: exit status 1, out: `The user name or passphrase you entered is not correct.` 最初、credentialsファイルがおかしいのかな?とか、awscliが死んでるのかな?とか疑ったのだけど、credentialsファイルは問題なく、awscliも私と同じバージョンにしたけど、エラーは解消しなかった。 そこで、ネットで調べた所下記issueがヒットした。 https://github.com/docker/for-mac/issues/2295 Dockerのconfig.jsonに書いてある一行を削除しろと書いてあった。 $ vim ~/.docker/config.json { "auths": { "XXXXXXXXXXXXXXXXXXXXXXXX.amazonaws.com": {}, "https://XXXXXXXXXXXXX.amazonaws.com": {} }, "HttpHeaders": { "User-Agent": "Docker-Client/18.06.0-ce (darwin)" }, "credsStore": "osxkeychain" こんなファイルがあるので、`”credsStore”: “osxkeychain”` をまるっと消してあげた。 そうしたら無事(?)にログインできるようになった。 この項目はどうやらユーザーの証明書をOSXのキーチェーンに保存するもののようで、恐らくそれがうまく取得できなくなったのだと思われる。 http://docs.docker.jp/engine/reference/commandline/login.html#creadentials-store 開発者の方も、OSXをアップデートしたら発生するようになったと言われたので、アップデート周りでおかしくなってしまったのかもしれない。 手動で削除しなくても、docker logout とかでもいけるようなので、もし同じ事象が発生したら試す価値あり。
-
AWS Fargate ECS/EKS祭り 8/3(金) AmaozonWebServices目黒セントラルスクエア AWS Fargate & Amazon ECS/EKS最新情報 ECS AWS 西谷さん(@Keisuke69) コントロールプレーン=コンテナの管理をする場所(ECS/EKS)どこでコンテナを動かす?生死は?デプロイ時にどこに配置する?など データプレーン=実際にコンテナが稼働する場所(Fargate/EC2) ECSの話 ローンチされてから数年 数百万インスタンス/数億コンテナが毎週起動 プロダクションでコンテナ運用を支援するために開発されている CloudWatchLogと簡単に連携 CloudWatch Iventと連携 Fargateのローンチ 7月からTokyoリージョンサポート AutoScallingをユーザー側で考えなくても良い(ECSと同じ) スケジューラ、LBなどはECSと同じで利用可能 課金はCPUとメモリが秒単位 FarageteはVPCネットワーク利用のみ ALB/ELBをサポートしている パーミッションタイプ(Cluster/Application/HouseKeeper) CloudWatchでモニタリング Farfateで難しいもの Windows Containers GPU Support docker exec デバッグ SpotやRIベースの価格モデルの適用→必要ならEC2モード Lambdaのほうがよい場合 イベント・ドリブン ミリ秒単位のコンピュート ランタイム管理したくない 分散バッチコンピューティング コンテナのAutoScaling ECS Trackingとの連携がおすすめ SLA99.99%(ECSと同じ) EKS k8sをプロダクションを運用している人→ちらほら k8sは可用性のためにAZをまたいで3つ作成が必要 on AWS k8sは人気があるが自前構築が大変… AmazonEKSはずっとプレビューだったが、6月末で一般公開になった(AWS、Kubernetesを簡単に実行できる「Amazon EKS」を正式リリース) Confirmability CNI plugin ENI Secondary IP LB: CoreOSALB エンドポイント認証はIAMできる FlutendでCloudWatch Logsと連携が簡単 WorkerのメトリックスはCloudWatchで取れる AmazonECS + AmazoneEKS + Faragte 連携予定 コンテナ化したアプリケーションをAWSを動かすためのベストプラクティス 福井さん(@afukui) カナリアデプロイ/ブルー・グリーンデプロイ がやりやすいのがコンテナのメリット マイクロサービス化している方? – ちらほら コンテナを利用した開発に必要な技術要素 アプリのステートレス化 レジストリ コンテナの中にいれるのはステートレスなアプリに ステートが必要なものはコンテナの外に RDBMS -> RDS オブジェクト -> S3 Twelve-Factor App(The Twelve-Factor App) レジストリの自前運用は大変なのでマネージドを使うのがおすすめ CI/CDパイプラン 自動化するメリットは誰がデプロイしても同じ結果になる デプロイ職人(!
-
会社ではサーバーへのプロビジョニングにAnsibleを利用している。 Ansibleは久しく使っていなかったので、改めて勉強するべく手元のMacのDockerにプロビジョニングする方法を調べた。 最初、コンテナでSSH待受ができないとだめ?とか、コンテナにAnsibleをインストールしておかないとだめ?みたいに思っていたが、全くそんなことはなかった。 Ansible2.0以降ではDocker connection pluginというのが提供されており、記述を加えるだけで簡単に利用できる。 環境 docker for mac 18.03.1-ce-mac65 ansible 2.5.2 利用方法は下記の通り。 1.Ansibleのインベントリファイルにコンテナ名を記述する。 [docker_host] localhost [container] amazonlinux 2. マスターのplaybookにconnection dockerを記述する。 $ vim site.yml - hosts: amazonlinux connection: docker <-- ここの部分 roles: - nginx たったこれだけでdockerへプロビジョニングすることができる。※docker-pyも昔は必要だったようだがansible2.5の私の環境ではインストールしなくても、dockerへansibleでプロビジョニングできた。 $ ansible-playbook -i hosts site.yml -C PLAY [amzonlinux] ********************************************************************************************** TASK [Gathering Facts] ********************************************************************************************** ok: [amzonlinux] TASK [nginx : install nginx] ********************************************************************************************** ok: [amzonlinux] TASK [nginx : copy conf] ********************************************************************************************** ok: [amzonlinux] => (item={u'dest': u'.
-
やろうやろうと思ってできていなかった自宅サーバーのOSアップデートと、アプリケーションのDocker移行をこのGWでやってました。 サーバー構成図(変更前と変更後) 変更前 CentOS6 apache+mod_php(PHP5.4)で全てのアプリケーションを動かしていた 設定変更時はファイルの日付で世代管理! 変更後 CentOS7 Docker(docker-compose)で分けているので、アプリケーションに応じてPHPのバージョンを変えている。(PHP7だと既存のPukiwikiが動かなかった…) itamaeでプロビジョン(git管理,RaspberryPiのgitbucketサーバー) 移行時に困った点 移行時に困ったのはfirewalldとdockerの衝突でした。 標準搭載のfirewalldを使用するためにセキュリティ設定を入れていたのですが、dockerのコンテナ起動時にdocker自身がiptablesコマンドでDNATを追加しているらしく、それが失敗してdockerへ接続できないことがありました。 結局、良い解決方法が見つからず、firewalldは諦めてiptables-servicesを動かすことにしました。 移行して良かった点 docker-composeでアプリケーションを管理しているので、手元で色々やりやすくなりました。(検証とか) ホストサーバーとアプリケーションがDockerを中心に分離出来ているので、管理する側としても状態が判別しやすくなりました。 今回itamaeを初めて使ってみましたが、普段仕事ではPuppet(どちらもRuby製のツール)を使っているので、erbなどは同じように使えてとても導入しやすかったように感じてます。 Gitで管理しているので、ファイルの日付による世代バックアップが不要になりました笑 今後の課題 今回はとにかくOSのアップデートとdockerへ移行することを目的にメンテナンスを実施したので、いくつかのアプリケーションは移行作業時には含まず、後回しにしたのでそれらをゆるりとdocker上で動かしていきたいです。
-
Raspberry Pi3を去年の夏くらいに買いまして、pythonでLチカしただけで放置しててさすがにもったいないなぁと思ってた矢先、ARMでもDockerが動くらしいという情報をネットで知ったのでやってみることにしました。 とは言え、docker runだけだとつまらないのでgitbucketとか、gitクローンが動いたら最高かもと思ってgitbucketを動かすことにしました。 環境 Raspberry Pi3 Rasbian [code lang=”bash”] pi@raspberrypi:~ $ sudo cat /etc/os-release PRETTY_NAME=”Raspbian GNU/Linux 8 (jessie)” NAME=”Raspbian GNU/Linux” VERSION_ID=”8″ VERSION=”8 (jessie)” ID=raspbian ID_LIKE=debian HOME_URL=”http://www.raspbian.org/” SUPPORT_URL=”http://www.raspbian.org/RaspbianForums” BUG_REPORT_URL=”http://www.raspbian.org/RaspbianBugs” pi@raspberrypi:~ $ uname -a Linux raspberrypi 4.4.13-v7+ #894 SMP Mon Jun 13 13:13:27 BST 2016 armv7l GNU/Linux [/code] Dockerのインストール Raspberry PiでDockerをインストールするのはめちゃ簡単で、ワンライナーを実行するだけです。 [code lang=”bash”] pi@raspberrypi:~ $ curl -sSL https://get.docker.com/ | sh [/code] とは言え、私の環境だとなんかapt-get updateでコケまくってて、どうもミラーリストが死んでる?っぽいような状態だったので、ミラーリストを日本のに変更するなどしました。 普通にapt-get updateが動けば、問題なくインストールできると思われます。 [code lang=”bash”] pi@raspberrypi:~ $ sudo cat /etc/apt/sources.
-
先日、Dockerでnginxとphp-fpmを起動する手順とDockerfileを作る手順と注意点と参考サイトを公開しました。 今回はより便利なDocker Composeを使った複数のコンテナの管理を書いていきます。 今回も前回同様に、Docker初心者向けの記事となります。 ※なお、docker runやDockerfileを作成したことが無いと、どういったメリットがあるか感じにくいと思いますので、事前にdocker runしたりDockerfileまで作成してみることをおすすめします。 Docker Composeとは docker-composeの公式リファレンスには下記のように記載があります。 複数のコンテナを使う Docker アプリケーションを、定義・実行するツールです。Compose はアプリケーションのサービスの設定に、Compose ファイルを使います。そして、コマンドを1つ実行するだけで、設定した全てのサービスを作成・起動します。 今まではDockerfileでビルドしたイメージをdocker runのオプションを駆使して、複数コンテナを一つずつ実行していましたが、docker-composeを使うことで簡単に複数のコンテナがリンクした環境を作ることが可能です。 では実際に試してみます。 Docker ComposeでWordPress環境を作る docker-compose.ymlというファイルにyaml形式で、コンテナの情報を記載していくことで、簡単にコンテナ環境を作成することができます。 公式リファレンスにdocker-composeを使って、WordPress環境を作成する手順が記載されていますので、まずはその通りに実施します。 環境 docker for macで進めていきます。バージョンは下記の通りです。 ※docker 1.8以降からはdocker tool boxを利用するようになったようで、macであればdocker for macと一緒にtool boxの中にdocker-composeが含まれているかと思います。もしdocker-composeがなければ、dockerの公式サイトからインストールを実施してください。 $ docker -v Docker version 1.13.0, build 49bf474 $ docker-compose -v docker-compose version 1.10.0, build 4bd6f1a ディレクトリを作成する どこでも良いのでGit管理しやすいように適当な場所にディレクトリを作成して、移動します。 $ mkdir my-wordpress $ cd my-wordpress docker-compose.ymlを作成する。 公式リファレンスの内容をコピーして、docker-compose.ymlにペーストします。 version: '2' services: db: image: mysql:5.7 volumes: - "