Dockerやコンテナについての理解を目指す入門テキストです。 CloudNative Days Kansai 2019 - #CNDK2019 における発表資料です。 https://cloudnativedays.jp/cndk2019/Read less
次々と発表されるオープンな日本語大規模モデル どうなっているの??という感じですよね。 我らがnpakaさんは、さっそくGoogle Colabで動かしていらっしゃいます。 ただ、Google Colabだと毎回モデルのダウンロードが大変なので、ローカルでDocker使って手軽に動かせるといいな、ということでやってみました。 以下GitHubのリポジトリにDockerfileとサンプルプログラムをおいています。チャットっぽいことをできるようにしています。 上記で、サイバーエージェントとリンナのLLMが両方動きます。 使用環境 前提となる環境です。使用しているPCのスペックは以下です。 項目 内容
やあ!id:cockscombです。日々の生活に役立つちょっとした知識を紹介していきます。最近は、Apple WatchやPixel Watchみたいな、ナントカWatchのリリースが多いですね。でも今日紹介するのは、WatchはWatchでも、Docker Compose Watchです。 Docker Composeは、複数のコンテナを扱った開発に用いる道具で、コンテナを活用した開発では当たり前に使われている。そのDocker Composeに、ファイルの変更を監視してコンテナの再構成を行わせるのが、Docker Compose Watchだ。Docker Compose 2.22以降で利用できる。最新のDocker Desktopにも付属している。 ホットリロードとコンテナ開発 Docker Compose Watchがどういうものかを説明する前に、Next.jsのホットリロードにつ
Dockerfileを解析、最適化やベストプラクティスをガイドしてくれる「Docker Buildチェック」機能が正式版に Docker社は、Dockerfileを解析して最適化とベストプラクティスをガイドしてくれるツール「Docker Buildチェック」機能の正式版をリリースしました。 Docker Buildチェックは、WindowsやMacなどのデスクトップ環境にDockerコンテナ環境を簡単に導入できるDocker Desktopの最新版として7月29日にリリースされた「Docker Desktop 4.33」の機能として提供されます。 Dockerfileとは、Dockerコンテナを構成するさまざまなファイルを取得し、ビルドを実行してDockerコンテナイメージを作成する際の手順書といえます。 そのため、Dockerfileはビルドが正常に実行されるようにバグがないように手順を
こんにちは、後藤です。今回はAWS構成における踏み台についての記事です。 データベースなどのインターネットに繋げたくないリソースに踏み台リソース経由でアクセスさせることは、セキュリティ設計としてよくある構成だと思います。 今回はその踏み台リソースに「ユーザーログイン有無を検知して自動停止する」ロジックを組み込んだ方法を共有します。 また、一般的によく用いられるのはEC2だと思いますが、今回はECS on Fargate(以降はFargateと略)を使います。しかも自動停止ロジックにLambdaを使いません!!コンテナの中で完結させます。 踏み台を設計する時に気になること そもそも踏み台について設計する際に何が気になるのでしょうか。それはOS管理負担と自動停止です。 踏み台にEC2を用いるとOSパッチ適用などの運用コストが発生します。業務系サーバでないのに心労が重なるのはなるべく避けたいとこ
概要 前提 規約 コンテナはエフェメラル(短命:ephemeral)であること .dockerignoreを有効活用する 不要なパッケージのインストールを避ける コンテナ毎に1つのプロセスだけ実行 レイヤーの数を最小に 複数行の引数はアルファベット順、改行すること Docker network 概要 bridge none host overlay ipvlan macvlan Docker Volume 概要 bind mount volume tmpfs mount Dockerfileを扱う まずはDockerfileを作成する! FROM:ベースイメージを作成 RUN: 任意のコマンドを実行する WORKDIR: ワークディレクトリを追加する レイヤーの確認 コンテナの生成と停止 imageを作成 runでコンテナを起動 stopでコンテナを停止 pruneでDockerのお掃除
みなさん機械学習系の環境構築はどうやってますか? 僕は最近は Docker を使った管理を行っています。 特に師匠も居なかったので、ぐぐったり人のイメージを見たり手探りで docker をつかいつかいしている中で、最初からやっとけばよかったなーということがいくつかあるのでメモとして残しておきます。 大きく2つです。 キャッシュは消す テストを書く キャッシュは消す ライブラリをいろいろと install すると大抵の場合ダウンロードしたファイルを保存されている場合が多いです。何かのタイミングで再びそのライブラリをインストールする際にはダウンロードしたファイルを使って、素早くインストールすることができます (この仕組みがキャッシュです)。 キャッシュがあると容量が重くなるという欠点があります。重たいイメージは pull に単に時間がかかりますから、システムとしてデプロイする時にトラフィックが
人に説明するときに記事あると便利なので、開発環境向けのDockerfileとdocker-compose.ymlを書いておく。 Dockerfile FROM ruby:3.0.0 WORKDIR /app # Using Node.js v14.x(LTS) RUN curl -fsSL https://deb.nodesource.com/setup_14.x | bash - # Add packages RUN apt-get update && apt-get install -y \ git \ nodejs \ vim # Add yarnpkg for assets:precompile RUN npm install -g yarn # Add Chrome RUN curl -sO https://dl.google.com/linux/direct/google-ch
はじめに 先日、僕が担当する業務でECS/Fargate利用を前提にDevSecOpsアーキテクチャをデザインし、社内のAWS勉強会にて登壇する機会をいただきました。 本ブログでも内容をかいつまんでご紹介できればと思います。 AWSによらず、コンテナを利用されている方にとって、一つのプラクティス例としてご参考になれば幸いです。 ※コンテナ自体の説明や必要性に関する内容は省略していますm(_ _)m そもそもDevOpsとは? DevSecOpsの導入意義をお伝えするた前に、まず軽くDevOpsの意義をお伝えします。 ※とは言え、この記事をご訪問されている方にとっては「何をいまさら...」な内容かもしれませんし、ググればDevOps自体の情報はたくさん見つかりますので、重要なポイントのみ述べることにします。 DevOpsとは、一言で述べれば、開発チームと運用チームが協力してビジネス価値を高め
前提 コンテナを用いてアプリケーションのワークロードを構築することにはいくつかの利点があります。 なかでも、下記に上げられるポータビリティと環境の再現性は非常に強力です。 ポータビリティ コンテナは、アプリケーションとその依存関係をコンテナ内にパッケージ化します。 これにより、開発環境で構築したコンテナを本番環境にデプロイする際にも、一貫した動作が期待できます。 異なる環境間でアプリケーションを移行する際に、互換性の問題や依存関係の不一致が生じるリスクが低減され、ポータビリティが高まります。 環境の再現性 コンテナは環境に依存しないため、開発者が特定の環境でアプリケーションを構築した場合でも、他の開発者や運用チームが同じ環境を再現することが容易です。 コンテナイメージにはアプリケーションのコードとその実行環境が含まれており、イメージを共有することで他の人が同じ環境でアプリケーションを実行で
Amazon Web Services ブログ AWS Copilot のご紹介 Amazon Elastic Container Service (Amazon ECS) をご利用中、あるいはご利用を検討されている皆さまへ 本記事でご紹介する AWS Copilot は Amazon ECS CLI の後継に当たるものです。日本はこの ECS CLI を多くのお客様にご利用いただいている地域の1つであることに加え、ECS でのコンテナ実行をもっと簡単に行えるようにしたい、シンプルなワークフローを実現したいというリクエストを多数いただいていることから、本記事を英語記事と同じタイミングで公開することにしました。 Amazon ECS でのコンテナ実行に新たな体験を提供する AWS Copilot の紹介記事です。お楽しみください! −トリ (皆さまからの Copilot へのフィードバック、
イテレーションの速さがあなたの生産性を左右する。どうも、かわしんです。生産性の高いプログラマって1つ1つの試行が素早い(自動化しているかツールを使っている)ためにものすごいスピードで開発できていると思うんですよね。 さて、最近 Python で開発をしているのですが、世の中の Docker と Pipenv の開発環境を調べてもろくなものがなかったので、自分でテンプレートを作りました。いわゆる「俺の考える最強の Pipenv + Docker 開発環境」というやつです。 リポジトリはこちらになります。 github.com 特徴としては、以下の2つが大きいです。 pipenv install をコンテナ起動時に行うため、docker イメージを作り直す必要がない pipenv shell 相当の仮想環境のアクティベートを自動で行う なぜ Docker + Pipenv なのか Docker
BusterとかStretchという名前が見慣れない方もいるかもしれませんが、これはLinuxディストリビューションとしてシェアの大きなDebianのコードネームです。 Debianバージョンが少し古いStretchの方がちょびっとサイズが小さかったりはしますが、まあ実用的にはサポートが長い方がいいですよね。slimを使ってGCCとかのコンパイラを自前でダウンロードしている記事とかもたまに見かける気がしますが、マルチステージビルドであれば、そんなにケチケチしなくていいのと、パッケージダウンロードは逐次処理なので遅く、処理系が入ったイメージのダウンロードの方が高速です。並列で処理されるし、一度イメージをダウンロードしてしまえば、なんどもビルドして試すときに効率が良いです。また、多くのケースでネイティブのライブラリも最初から入っており、ビルドでトラブルに遭遇することはかなり減るでしょう。 Py
CTO室SREの@sinsokuです。 Dockerイメージのビルドを高速化するため、試行錯誤して分かった知見などをまとめて紹介します。 AWSのインフラ構成 assetsもECSから配信し、CloudFrontで /assets と /packs をキャッシュする構成になっています。 Rails on ECS デプロイ時にassetsが404になる問題 以前の記事に詳細が書かれているため、ここでは問題の紹介だけしておきます。 Rails等のassetsファイルをハッシュ付きで生成し配信するWebアプリケーションの場合、ローリングアップデートを行うと、アップデート時に404エラーが確立で発生してしまいます。 引用: メドピアのECSデプロイ方法の変遷 Dockerfile 実際のDockerfileには業務上のコード、歴史的な残骸などが含まれていたので、綺麗なDockerfileを用意しま
はじめにこんにちは、Finatext で保険事業のプロダクト開発をしている @toshipon です。今回は以前の Fin-JAWS のイベントで少し紹介させていただいた、我々の現場で取り組んでいる、大規模API開発における Swagger を用いたAPI仕様のドキュメント運用方法について紹介いたします。 概要我々の現場では、API ベースのWeb Application を開発する際に、Swagger を用いて API 設計をしたり、BFFサーバー開発者やフロントエンド開発者とのコミュニケーション手段として活用しています。 ただし、Web Application の規模が大きくなってくると、Swagger の 定義ファイルは肥大化してしまい、メンテナンスが困難になってきます。 今回は、Web Application の規模が大きくなっても耐えうる Swagger 定義ファイルの運用方法を
はじめにSHIFT DAAE の shinagawa です。表題の通りNode.jsで作成したコンテナのイメージサイズの軽量化に挑戦しました。 背景近年の多様化・高速化するビジネスに対応するITシステムの構築を実現する「クラウドネイティブ」の構成要素の一つとして 「コンテナ」という仮想化技術が存在し、当部門でも活用を進めております。 このコンテナイメージを作成するにはアプリケーションコードやライブラリ・モジュールなどの依存物、ランタイム等を1つのイメージとして組み立てて作成しますが、 この構成要素が増えるとイメージサイズが肥大化し保管時のストレージのコストの増加やイメージの転送、環境への展開に時間がかかることになります。 従ってイメージのサイズを削減することは、これらの点を改善することにつながります。 ここではネット上で紹介されている、あらゆる打ち手を組み合わせてコンテナイメージの軽量化に
Rust + Docker + GitHub Actions = めちゃ遅い 以前、GitHub Actions 上の Rust ビルドを高速化する記事を書いたけど、 今回は Kubernetes 環境にスムーズに移行できるよう Docker イメージ化するという要件も加わったことで、改めて試行錯誤する必要が出てきた。 それぞれに対するビルド速度の最適化は存在しているものの、3つ (Rust, Docker, GitHub Actions) すべてを満たすとなるとコピペで終わるほど情報がまとまってないし、見つけた Tips もちょっと古かったり、これというものは見つけられなかった。 公式ドキュメントを見ると正当進化していて新しいオプションが生えていたりしたので、賞味期限は短そうだけど、自分の試行錯誤の結果を残しておこうと思う。 成果としては 12 分 22 秒かかっていた Rust アプリ
TIG/DXの渋川です。 ソフトウェアの世界では、ツールや言語の進歩があって、もはや古い知識になっているにも関わらず、古い知識がベストプラクティスと呼ばれて蔓延し続けている例があります。Dockerだと「RUNをまとめよう」というのがそうです。かつてはこれは常に行うべきプラクティスでしたが、現代だとそうじゃないケースもあり、デメリットもあります。 https://www.docker.com/company/newsroom/media-resources 1. ただファイルが増えるだけのケースであれば気にしなくていい次の2つのファイルで実験してみます。ベースイメージに、10MBのファイルを作成するコマンドをふたつ並べたものです。 FROM debian:bullseye-slim RUN dd if=/dev/zero of=dummy1 bs=1M count=10 RUN dd if
クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここでVMwareの伊藤氏が「脱 Dockerfile! Cloud Native Buildpacksとkpackを使った簡単で安全なイメージ」をテーマに登壇。まずは、Dockerfileの問題点とCloud Native Buildpacksについて紹介しました。 トーク内容の目次 伊藤裕一氏(以下、伊藤):「脱 Dockerfile! Cloud Native Buildpacksとkpackを使った簡単で安全なイメージ」という内容について、伊藤がお話しします。 目次です。最初にDockerfileのおさらいと、問題点を話します。そして、Dockerfileを使わずにビルドを実施するCloud Native Buildpacks(CNB)の概要と
whichを使わない一番の理由はcoreutilsに入ってないから(commandはたいていのshellでbuiltin functionになっている)。 ash(1): command interpreter - Linux man page dash(1) - Linux manual page Bash Builtins (Bash Reference Manual) たぶんDockerfileでいろいろやっているときに身についた振る舞いだと思う。 ポータビリティを高めるとかの高い意識ではなく、何度もcommand not foundに遭遇して面倒になったことが主な動機で、そこから派生してwhichコマンドの存在を無視する(頼らない)ようになった感じ。 あと、軽量なDockerイメージを作るのがかっこいいと見做された時期があって(時期というより原則だけど)、インストールするパッケージ
おなじみの画像 JavaやScalaといったJVM言語のDockerイメージは、JVMを同梱しなければならない都合で肥大化しがちである。特に何もしなくても、例えば一般的なamazoncorretto:21のイメージサイズは217.7 MBもある。 hub.docker.com これにさらにビルド済みのJARファイルが載ってくるので、結構大きくなってしまうのだ。 そこで、Scalaのコンテナイメージのサイズをなんとか小さくできないかと、考えた。すると、JVMを使ったまま70 MiBくらいに縮めることができた。 github.com コンテナイメージのサイズを小さくするために、何をしたかを書いていく。ちなみに題材としたアプリケーションはちょっとしたHello, Worldをするだけのもので、ライブラリはCatsに依存させた。 JVM使う編 マルチステージビルドを行う Alpineなどの軽量ラン
業務やプライベートでのハンズオンを通して得た知見を元に、dockerfileの実践的な書き方を記載いたしました。 軽量なdocker imageを作る観点とセキュリティーの観点を踏まえた内容になっております。なにか付け足す点などあればコメントいただければと思います。 軽量なimageを作る観点 軽量なimageの使用 Dockerfileでimageを指定する際に、軽量なimageを使用することが進めれている。 docker docsでも代表的な軽量なimageのalpineをおすすめしている。 Whenever possible, use current official images as the basis for your images. We recommend the Alpine image as it is tightly controlled and small in s
エムスリーエンジニアリンググループ AIチームの笹川です。 バスケと、ロードバイクが趣味なのですが、現在、NBAのplayoffと、Tour de Franceが同時に開催されていて大変嬉しい毎日を過ごしています。 特にNBAのplayoffは、連日overtimeとなるような激戦や、giant killingがあったりのアツい戦いが繰り広げられていて最高です。 そういう状況なので(?)、今回は先日取り組んだ、Pythonの機械学習バッチを実行するdocker imageのサイズ削減についてのアツい戦いについて紹介したいと思います。 膝の上に登って寝る為に、筆者がデスクに戻るのを机の下で待ち構える犬氏(かわいい) 今回の取り組みでは、もともと3GB程度だったPythonのML用のimageを、約2.0GBに削減することができました(それでもなかなかのサイズ。MLのimageは特に大きい印象
BuildKit supports loading frontends dynamically from container images. Images for Dockerfile frontends are available at docker/dockerfile repository. To use the external frontend, the first line of your Dockerfile needs to be # syntax=docker/dockerfile:1.3 pointing to the specific image you want to use. BuildKit also ships with Dockerfile frontend builtin but it is recommended to use an external i
今回は Elasticsearch + Sudachi でユーザー辞書を使う Dockerfile を作ったので作り方を共有します。 Elasticsearchのバージョンは現行の最新(v7.4.0)ですがv6.8あたりでも動くことを確認済みです。 Sudachi とは Sudachi は日本語形態素解析器です。株式会社ワークスアプリケーションズ下の機関であるワークス徳島人工知能NLP研究所が開発しています。複数の分割単位をサポートしているなどの特徴があります。 ドキュメントはこちら https://github.com/WorksApplications/Sudachi/#sudachi-%E6%97%A5%E6%9C%AC%E8%AA%9Ereadme 今回のハンズオンの最終構成 最終的に下記のような構成を目指します。 . ├── docker-compose.yml └── elas
なお、distrolessのイメージは2種類(3通りの名前)がありますが、Python 3.5はバグ修正はせず、セキュリティ修正のみでサポート期限が2020/9/13というステータスなので、本エントリーでは3.7の方のみを扱います。 gcr.io/distroless/python3: Python 3.5.3 gcr.io/distroless/python3-debian9: Python 3.5.3(上のイメージと同一) gcr.io/distroless/python3-debian10: Python 3.7.3 一応サンプル等もありますが、どれも1ファイルで構成されたサンプルスクリプトばかりです。前回のsite-packagesにコピーする方法を軽く試したところうまく動かず、シェルもpipもensurepipもないため、ビルドイメージにすることもできません。いろいろ調べた結果、
金山(@tkanayama_)です。先日終了したKaggleの"M5 Forecasting"というコンペに参加した際、クラウドやCI/CDの勉強も兼ねて、AWS, GitHub Actionsを使って遊んでみました。 免責 N番煎じだったらすみません。一応、同じことをやっているネット記事は見つかりませんでした。 私はクラウドなど勉強中の身分ですので、もっといいやり方がある or 説明が間違っている、などありましたら教えてください。 私がこのシステムを使って参加したコンペの順位は5,558チーム中1,000,000,000位だったので、Kaggleで勝てるかどうかは別問題のようです :pien: この記事のゴール 下記のようなシステムを構築することをゴールとします。 ユーザーがやることは2つ(図中でユーザーから伸びている黄色矢印)で、 実装したコードをgit pushし、 AWSコンソール
Amazon Linux 2 の Dockerイメージから開発環境を作り Visual Studio Codeで接続してみる Amazon Linux 2のDockerイメージから開発環境として使うコンテナを作り、Visual Studio Codeで接続してみました。 コンテナは以下をインストール or 可能としてみました。 AWS CLIをインストールする。かつクレデンシャルはローカルのものをコンテナ内でも使えるようにする。 (開発言語として)Go言語をインストールする。 ローカルマシンとコンテナで共有できるフォルダを作成する。 以下、今回作成した「docker-compose.yml」と「Dockerfile」について書いていきたいと思います。 作成したもの ローカル環境について 本作業はMacで行いました。docker-composeとDockerがインストールされているものとしま
本記事ではDockerにおける秘密情報を (I) コンテナを起動する際に使用する秘密情報 と (II) イメージをビルドする際に必要となる秘密情報 に分類して考え、特に後者を安全に取り扱うための方法について整理します。 コンテナ起動時の秘密情報とイメージビルド時の秘密情報 (I) コンテナを起動する際に使用する秘密情報としては、例えば mysql イメージ の環境変数 MYSQL_ROOT_PASSWORD があります。コンテナの起動時にこの環境変数を与えると MySQL の root ユーザーのパスワードがその値になるというものです。 あるいは、例えば Laravel などのWebアプリケーションで、バックエンドDBへの接続情報を含んだ設定ファイルを Docker ホスト側に用意しておき、コンテナ起動時にその設定ファイルをマウントするというようなケースも考えられます。 いずれにしても、こ
前回(第1回)は、Dockerコンテナに対応するアプリケーションを開発・実行するために、Docker Composeというツールを使うのが便利ということで、例としてDocker Composeを使ってWordPressをコマンド1つで実行する方法を紹介しました。WordPressのような、しっかりとしたアプリケーション以外でもDocker Composeが使える場面があります。 今回は、Docker Composeを使ってウェブサーバ(Apache httpd)を実行し、コンテンツを表示する例を見ていきましょう。 なぜDocker Composeなのか? 単純にウェブサーバとして実行するアプリケーションであれば、Dockerだけで何ら困らないでしょう。例えば、Apache httpdサーバを実行するには、次のようにしてコンテナを実行できます。 docker run -d httpd しかし
運用管理が楽になり、クラウドとの親和性も高い――エンジニアならば避けては通れない「コンテナ」技術のメリットは、既に多くのエンジニアが肌で感じているものだろう。コンテナアプリケーションを動かすまでには、コンテナイメージを作成し、レジストリにアップロードし、そのイメージをデプロイ先にダウンロードし、コンテナを実行するというプロセスを踏む。コンテナアプリケーションの構成はDockerfileなどのテキストで表現できることもあり、構成管理は可読性も高い。 では、そこに“脅威”はないのだろうか? コンテナ技術が普及期に入ったこともあり、昨今では“コンテナセキュリティ”に関しても注目が集まっている。しかしコンテナセキュリティが指すポイントについてはさまざまな意見があり、「いったいどこを守るべきなのか」「どこに脅威があるのか」がよく分からないというエンジニアも少なくないだろう。 そこで今回、トレンドマイ
Happy New Year! 年末、年始があっという間に終わり、明日は成人の日。 来週からコーディングのオンラインクラスを受けることになった。4−6ヶ月になりそうであるが、無事乗り切れるのか、少々不安も。javascriptを習得するコースなため、最終的にnode.jsのサーバーサイドでのコーディングもできるようになるまでの知識を得られるよう頑張ろう。node.jsの環境構築に不可欠ともいえるdocker。 今回は、10 best practices to containerize Node.js web applications with Docker の翻訳記事のご紹介です。 今回は、特に翻訳に苦労しました。読みにくい部分もあると思いますが、どうぞ最後までお付き合いください。 Dockerでnode.jsウェブアプリケーションをコンテナ化するための10のベストプラクティス Liran
本記事は、2022年5月に開催されたTechFeed Conference 2022のセッション書き起こし記事「コンテナビルド最新事情 2022版(inductor) — TechFeed Conference 2022講演より」を転載したものです。オリジナルはTechFeedをご覧ください。 それではこれから、私@_inductor_が「コンテナビルド最新事情」ということでお話をしていきます。 今日は主に4つの話をしていきます。ちょっと駆け足になってしまいますが、コンテナビルド高速化に向けた4つの機能およびポイントについてお話しします。 今回お話すること Dockerfileの新しい記法 まず最初に、Dockerfileに新しい記法がいくつか増えています。それを実装しているのは BuildKitと呼ばれるDocker発のオープンソースのソフトウェアがベースになっていて、Dockerf
こんにちは。Tably よういちろう(@yoichiro)です。 皆さんは普段GitHubをお使いでしょうか?お使いの方は、GitHub Actionsを使ってCI/CDしていますでしょうか? GitHub Actionsを使うことで、Pull Requestの作成や更新、あるブランチへのマージといったタイミングで、コードのフォーマットを整えたり、テストを走らせたり、本番環境にデプロイしたり、一連の作業が終わったことをチャットに通知したり・・・といったことを自動的に行うことができます。GitHubにはGitHub Marketplaceというアクションが公開されているマーケットプレースがあります。やりたいことがあった時に、一般的なものであればそこで見つけることができるでしょう。 ものすごい数のアクションがMarketplaceにて公開されていますが、たまたま僕が行いたかった動作をしてくれる
Linux Kernel Teaching¶ This is a collection of lectures and labs Linux kernel topics. The lectures focus on theoretical and Linux kernel exploration. The labs focus on device drivers topics and they resemble "howto" style documentation. Each topic has two parts: a walk-through the topic which contains an overview, the main abstractions, simple examples and pointers to APIs a hands-on part which co
今回は Docker で使える「ヘルスチェック機能」を試す.Release Note を読むと,機能としては Docker 1.12 から使えるらしく,3年前からあったなんて...!仕組みとしては,Docker デーモンからコンテナに指定したコマンドを定期的に実行する. Dockerfile 構文 「ヘルスチェック機能」を使う場合,まず Dockerfile に HEALTHCHECK を設定する.実行するコマンド以外に以下のオプションも設定できる.注意点として,--retries 以外は秒数を指定するため,表記は 5s のように単位も付ける. --interval=DURATION (default: 30s) --timeout=DURATION (default: 30s) --start-period=DURATION (default: 0s) --retries=N (defa
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く