docker stackとは swarmを作成するためのdocker composeファイルのようなもの この記事はudemyのdocker講座 Docker Mastery: with Kubernetes +Swarm from a Docker Captain を参考にし作成しています。 解釈の間違いなどがあるかと思いますがその時はコメントしていただけると幸いです。 又コミュニティガイドラインは守っているつもりですがQiitaを投稿し始めてまもないのでその際もコメントしていただけるとありがたいです。 version: "3" services: redis: image: redis:alpine ports: - "6379" networks: - frontend deploy: replicas: 1 update_config: parallelism: 2 delay: 10s restart_policy: condition: on-failure db: image: postgres:9.4 volumes: - db-data:/var/lib/postgresql/data networks: - backend environment: - POSTGRES_HOST_AUTH_METHOD=trust deploy: placement: constraints: [node.role == manager] vote: image: bretfisher/examplevotingapp_vote ports: - 5000:80 networks: - frontend depends_on: - redis deploy: replicas: 2 update_config: parallelism: 2 restart_policy: condition: on-failure result: image: bretfisher/examplevotingapp_result ports: - 5001:80 networks: - backend depends_on: - db deploy: replicas: 1 update_config: parallelism: 2 delay: 10s restart_policy: condition: on-failure worker: image: bretfisher/examplevotingapp_worker:java networks: - frontend - backend depends_on: - db - redis deploy: mode: replicated replicas: 1 labels: [APP=VOTING] restart_policy: condition: on-failure delay: 10s max_attempts: 3 window: 120s placement: constraints: [node.role == manager] visualizer: image: dockersamples/visualizer ports: - "8080:8080" stop_grace_period: 1m30s volumes: - "/var/run/docker.sock:/var/run/docker.sock" deploy: placement: constraints: [node.role == manager] networks: frontend: backend: volumes: db-data:

結論 コマンド curl -L https://github.com/docker/machine/releases/download/v0.16.2/docker-machine-Darwin-x86_64 >/usr/local/bin/docker-machine && chmod +x /usr/local/bin/docker-machine 以下のDoc通りのコマンドではDocker Machineをインストールすることはできませんでした。 ご注意を。 https://github.com/docker/machine/releases/ 本当にインストールしたかどうかを確認するコマンドは以下です。 コマンド docker-machine version みなさん、楽しいDocker Lifeをお過ごしください☺️ @ryu0121

概要 Github Actions にはセルフホストランナーと言う仕組みがある 以後、セフルホストランナー = ランナーと表現する。 1台のマシンで複数のランナーを動かしたい場合、コンテナで動かすことができれば最大メモリの指定など他への影響を抑えることが出来る。 コンテナで動かす手順をメモとして残す ざっくり処理の流れ Dockerfile で apt-get して必要なライブラリをインストール、ランナーのファイルをコピーしてベースとなるイメージを作成。 コンテナを起動し bash などでシェルからランナーの設定コマンドを実行 ランナーの起動コマンドを実行 コマンド実行しなければ設定できないのか? github で提示されている手順にまずは則るため (Dockerfile のみで完結するのが望ましいのが…) 検証環境 Windows10 Pro WSL2 Ubuntu 20.04 Docker Desktop 手順 WSL2 の Ubuntu で操作 以下内容で Dockerfile を作成 Dockerfile FROM ubuntu:20.04 COPY *.tar.gz /root COPY packages-microsoft-prod.deb /root # sudo せず root で実行するための設定 ENV RUNNER_ALLOW_RUNASROOT=0 # ランナーが .NET を使うのでインストールする RUN apt-get update && \ apt-get install -y ca-certificates && \ dpkg -i /root/packages-microsoft-prod.deb && \ apt-get update && \ apt-get install -y dotnet-runtime-5.0 Dockerfile と同じ場所に以下をダウンロードして配置 https://github.com/actions/runner/releases/download/v2.278.0/actions-runner-linux-x64-2.278.0.tar.gz https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb 以下コマンドでコンテナイメージをビルド docker build -t testrunner . docker images で確認 以下コマンドでコンテナを起動し bash で接続 docker run -i -t testrunner bash ランナーのファイルを解凍し、github のランナー追加時の configure に従い config.sh を実行する cd /root tar zxf actions-runner-linux-x64-2.278.0.tar.gz ./config.sh --url <githubのランナー追加対象URL> --token <トークン> ランナー名やラベルを適当に設定 run.sh で起動 ./run.sh バックグラウンドで実行する場合は & をつける

このチュートリアルは、「How to Develop Function Compute」シリーズの一部です。このチュートリアルでは、対話形式で依存関係をインストールする方法を説明します。 はじめに まず、この記事で紹介されているいくつかの重要な概念について、簡単に説明します。 Function Compute：イベントドリブンなサービスで、ユーザーはサーバーなどのインフラを管理する必要がなく、コードの作成やアップロードに集中することができます。Function Computeはコンピュートリソースを提供し、ユーザーはコードを実行する際に消費されるリソースに対して料金を支払うだけで、より弾力的にコードを実行することができます。Function Computeの詳細については、こちらをご覧ください。 Fun： Funcraftとも呼ばれ、Function Compute、API Gateway、Log Serviceなどのリソースの管理を支援するサーバーレスアプリケーション向けの開発ツールです。Funを使って、template.ymlファイルで指定したリソースを定義することで、リソースの開発、ビルド、デプロイを行うことができます。Funの詳細については、こちらをご覧ください。 注）本記事の操作は、Fun 3.0.0-beta.1以降のバージョンに適用されます。 依存するツール 本プロジェクトの開発は、MacOSをベースにしています。しかし、関係するツールはプラットフォームに依存せず、LinuxやWindowsのOSにも適用できます。例題を進める前に、以下のツールが正しくインストールされ、最新バージョンにアップデートされ、適切に設定されていることを確認してください。 Docker Fun FunはDockerをベースに、ローカル環境をシミュレートします。 MacOSユーザーは、homebrewを使ってこれらのツールをインストールすることができます。 brew cask install docker brew tap vangie/formula brew install fun WindowsとLinuxのユーザーは、この記事を読んで、これらのツールをうまくインストールしてください。 インストールが完了したら、まずfun configコマンドを実行して設定を初期化します。 注：Funのバージョンは必ず3.0.0-beta.1またはそれ以降のバージョンを使用してください。 $ fun --version 3.0.0-beta.1 背景 Function Computeでは、合意された成果物としてZipファイルを使用しており、通常はコードと依存関係を含んでいます。これらの依存関係は、一般的に、apt-getによってインストール・管理されるシステム依存関係と、NPMやpipなどの言語関連パッケージ・マネージャーによってインストールされる言語ランタイム依存関係です。 システム依存性は一般的に移植性がない システムの依存性は、通常、環境に関連しています。例えば、brew install brotliコマンドを実行すると、MacOSを使用する開発マシンにbrotliがインストールされ、Function Computeにパッケージ化されます。その後、ファイルを解凍するbrotliコマンドを実行するために関数を呼び出すと、関数の呼び出しに失敗します。また、Linuxを使用している開発機でも、関数の呼び出しに失敗することがあります。これは、システムが提供するパッケージ・マネージャでインストールされる実行プログラムやダイナミックリンクライブラリが、システムの種類やバージョンに強く関係しているためです。Mac、Windows、Linuxなどの異なるシステムにインストールされたプログラムやファイルは、相互に移植できません。 言語依存は移植不可能 一般的に、言語依存関係はプラットフォームに依存しません。例えば、Node.jsの依存関係をインストールするためにnpm install jszipコマンドを実行したとします。その結果、その依存関係は異なるOSや異なるNode.jsのバージョンで動作する可能性があります。言語プラットフォームの依存関係は、通常、ポータブルです。ただし、例外がある場合もあります。例えば、npm install node-ptyは、ネイティブバインディングを用いた例です。node-ptyモジュールのインストールは、いくつかのC/C ++コードに依存しており、それらはインストールの過程でコンパイルされます。C/C++コードは異なるプラットフォーム間で移植性がありますが、コンパイル後は移植性のないコードになります。 DSLスクリプトの限界 Fun 2.0はDSLファイル(fun.yml)を使って依存関係を一括してインストールすることをサポートしています。fun install —package-type pip tensorflowのように、日常的な開発のためのコマンドラインモードも用意されています。Fun 3.0では、新しいDSLファイル、すなわちFunfileを提供します。FunfileはDockerfileのシンタックスサブセットと考えてください。そのため、Dockerに慣れている開発者はすぐに始められるでしょう。 しかし、fun.yml、Funfile、コマンドラインモードのどれを使っても、開発者にとっては痛いところがあります。現在の環境が不明で、以下のような点が考えられます。 1) どんなソフトウェアがインストールされているか？ 2) 特定のディレクトリにどんなファイルがあるか？ 3) それぞれのファイルの内容と属性は何か？ 開発者には、インタラクションを伴うサンドボックス環境が必要です。しかし、この機能はFun 2.0にはありません。その代わり、ユーザーはfcli sboxコマンドを実行したり、fc-dockerで提供されるイメージを直接使用して、docker run --rm -it -v $(pwd):/code aliyunfc/runtime-python2.7:bashコマンドでコンテナを起動することが多いです。しかし、ユーザーはこれらの複雑なコマンドやパラメータを使用する前に、DockerとFunction Computeをよく知っている必要があります。 これらの問題を解決し、ユーザーの開発体験を向上させるために、Fun 3.0ではfun install sboxサブコマンドを提供しています。 コマンドラインパラメータ 以下のコマンドラインパラメーターを参照してください。 $ fun install sbox --help Usage: fun install sbox [-f|--function <[service/]function>] [-r|--runtime <runtime>] [-i|--interactive] [-e|--env key=val ...] [-e|--cmd <cmd>] Start a local sandbox for installation dependencies or configuration Options: -f, --function <[service/]function> Specify which function to execute installation task. -r, --runtime <runtime> function runtime, avaliable choice is: nodejs6, nodejs8, nodejs10, python2.7, python3, java8, php7.2, custom -i, --interactive run as interactive mode. Keep STDIN open and allocate a pseudo-TTY when in a interactive shell. (default: false) -e, --env <env> environment variable, ex. -e PATH=/code/bin (default: []) -c, --cmd <cmd> command with arguments to execute inside the installation sandbox. -h, --help output usage information クイックスタート Pyzbar_exampleプロジェクトを例に説明します。pyzbar_exampleプロジェクトには以下のファイルが含まれています。 $ tree . . ©À©¤©¤ fun.yml ©À©¤©¤ index.py ©À©¤©¤ qrcode.png ©¸©¤©¤ template.yml 0 directories, 4 files 次のスニペットは、template.ymlファイルの内容を表示しています。 ROSTemplateFormatVersion: '2015-09-01' Transform: 'Aliyun::Serverless-2018-04-03' Resources: pyzbar-srv: Type: 'Aliyun::Serverless::Service' pyzbar-fun: Type: 'Aliyun::Serverless::Function' Properties: Handler: index.handler Runtime: python3 Timeout: 60 MemorySize: 128 CodeUri: . インタラクティブモードでのサンドボックスの有効化 $ fun install sbox -f pyzbar-fun -i using template: template.yml root@fc-python3:/code# ls fun.yml index.py qrcode.png template.yml root@fc-python3:/code# exit exit $ template.ymlが存在するディレクトリで、fun install sboxコマンドを実行します。 -f/-- function：サンドボックスを起動するための関数を指定します。この例では，関数に設定されているランタイムはPython 3です。したがって，Python 3 環境のサンドボックスが有効になります。pyzbar-fun関数に対応するCodeUriディレクトリは，サンドボックス環境内の/codeディレクトリにマウントされており，サンドボックス環境でlsコマンドを実行した後に返されるファイルリストで確認できます。 -i/-- interactive：インタラクティブモードを有効にします。非対話型モードの使い方は後ほど紹介します。 template.ymlファイルが存在しない場合や，template.ymlファイル内の関数が設定されていない場合は，--runtimeパラメータを指定することで，インタラクティブ・モードが起動します。この場合，カレント・ディレクトリはサンドボックス環境の /code ディレクトリにマウントされます。 $ fun install sbox -r nodejs10 -i root@fc-nodejs10:/code# ls fun.yml index.py qrcode.png template.yml root@fc-nodejs10:/code# exit exit $ 上記の方法は、実験用のサンドボックスを一時的に起動する場合に適用されます。 fun-install を使って apt と pip の依存関係をインストールする 以下のコマンドを実行して、apt と pip をインストールします。 $ fun install sbox -f pyzbar-fun -i using template: template.yml root@fc-python3:/code# fun-install apt-get install libblas3 Task => [UNNAMED] => apt-get update (if need) => apt-get install -y -d -o=dir::cache=/code/.fun/tmp libblas3 => bash -c for f in $(ls /code/.fun/tmp/archives/*.deb); do dpkg -x $f /code/.fun/root; mkdir -p /code/.fun/tmp/deb-control/${f%.*}; dpkg -e $f /code/.fun/tmp/deb-control/${f%.*}; if [ -f "/code/.fun/tmp/deb-control/${f%.*}/postinst" ]; then FUN_INSTALL_LOCAL=true /code/.fun/tmp/deb-control/${f%.*}/postinst configure; fi; done; => bash -c 'rm -rf /code/.fun/tmp/archives' root@fc-python3:/code# fun-install --help Usage: fun local [options] [command] build function codes or install related depedencies for Function Compute Options: -h, --help output usage information Commands: apt-get install apt depencies pip install pip depencies build build function codes for Function Compute help [cmd] display help for [cmd] 非対話型モードでのサンドボックスの使用 pyzbar-fun関数のSandboxにプレインストールされたdebパッケージを表示するには、次のコマンドを実行します。 $ fun install sbox -f pyzbar-fun -c 'dpkg -l' using template: template.yml Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==================================-================================-============-=============================================================================== ii acl 2.2.52-2 amd64 Access control list utilities ii adduser 3.113+nmu3 all add and remove users and groups ii apt 1.0.9.8.4 amd64 commandline package manager ii apt-utils 1.0.9.8.5 amd64 package management related utility programs ii autoconf 2.69-8 all automatic configure script builder ii automake 1:1.14.1-4+deb8u1 all Tool for generating GNU Standards-compliant Makefiles ...(´Ë´¦Ê¡ÂÔÁËÐí¶àÐÐ) また、以下のコマンドを実行すると、外部コマンドの出力をパイプライン経由で内部システムに送ることができます。 $ echo hello | fun install sbox -r nodejs10 -i -c 'cat -' hello 注：標準入力を受け付けることを示す-iパラメーターを指定します。 概要 fun install sbox コマンドは，fcli sbox コマンドの代替コマンドです。fun install sbox コマンドは、対話モードのサポートに加えて、指定されたランタイムの指定された関数を介してサンドボックスを起動します。次に、fun install sboxコマンドは、インラインコマンドやパイプラインなどの非対話型モードでも使用することができ、スクリプトの作成が容易になります。 本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。 アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。 アリババクラウドの詳細は、こちらからご覧ください。 アリババクラウドジャパン公式ページ

概要 Docker CentOS8にnginx入れてみたにSSL化を追加した拡張版になります。 mkcertを利用して、ローカルのPCに認証局を立て、そこで署名を行った証明書をSSLに利用するようになります。 また、コマンドの実行を極力無くすをモットーに、起動コマンドもシェルで作成していますので環境構築はシステムに不慣れな方でも大丈夫！ と、願っています(笑) 環境 maxOS BigSur 11.2.3 Docker version 20.10.6 docker-compose version 1.29.1 Homebrew 3.1.11 構成 . ├── docker │   └── app │   ├── Dockerfile │   └── nginx │   ├── certs │   │   ├── localhost+1-key.pem │   │   └── localhost+1.pem │   └── conf.d │   └── default.conf ├── docker-compose.yml ├── up.sh └── web └── index.html 手順 1. docker-compose.yml作成 docker-compose.yml version: "3.9" services: app: build: context: ./docker/app volumes: - ./web:/web - ./docker/app/nginx/conf.d:/etc/nginx/conf.d - ./docker/app/nginx/certs:/etc/nginx/certs ports: - "80:80" - "443:443" ボリューム それぞれのボリュームは以下の用途です。 - web => ウェブコンテンツ - conf.d => nginxのconf - certs => 証明書と秘密鍵 ポート ssl化するために、443ポートもマッピングするようにしています。 2. Dockerfile作成 CentOS8の公式イメージを基にして、nginxをインストールしています。 Dockerfile FROM centos:centos8 RUN dnf -y update && \ dnf install -y nginx CMD ["nginx", "-g", "daemon off;"] WORKDIR /web 3. nginxのconf設定 HTTPアクセスはHTTPSにリダイレクトさせ、HTTPSでは証明書と秘密鍵をそれぞれ読み込むようにしています。 server { listen 80; server_name localhost; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name localhost; ssl_certificate /etc/nginx/certs/localhost+1.pem; ssl_certificate_key /etc/nginx/certs/localhost+1-key.pem; location / { root /web; index index.html index.htm; } } 4. 起動用のシェル作成 SSL化のためにmkcertを利用します。 up.sh #!/bin/sh brew install mkcert nss mkcert -install mkcert -cert-file ./docker/app/nginx/certs/localhost+1.pem -key-file ./docker/app/nginx/certs/localhost+1-key.pem localhost 127.0.0.1 docker-compose up -d 5. その他 5-1. index.html 今回は、動作確認用のindex.htmlを用意します。 (nginxのデフォルトページは、混合コンテンツのため。) index.html <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <title>テスト</title> </head> <body> <p>test</p> </body> </html> 5-2. .gitignore 蛇足ですが、ローカル用の証明書と秘密鍵をgitにあげなくていいように設定します。 .gitignore docker/app/nginx/certs/ 6. 確認 6-1. 起動 sh up.sh 6-2. nginx確認 https://localhost/ にChromeでアクセスしてみましょう。 通信が保護されていたらOKです。 6-3. 停止 docker-compose down 最後に 本当はdocker内でmkcertを利用するように頑張ったのですが、どうやらローカル上で認証局を立てないとブラウザで確認する際に有効な証明書として認識してもらえず断念しました。 何かいい方法をご存知の方がいれば、ぜひアドバイスください。

はじめに とある用件で、Pysparkなるライブラリを知り、早速ながらその感覚を掴むために実践してみましたー！ ウェブマーケ、広告運用をやっていた時はHiveやHadoopなどのHDFSに格納された広告配信データをSQLで取得し、ExcelまたはTableauでガリガリ加工して分析していた経験があったので、 今回は、取得する側ではなく、データを用意して入れる側の気持ちになって、挑戦してみました◎ アーキテクチャ（ざっくり） Dockerで、3つのコンテナを立ち上げる。 sparkのマスター 純粋にSparkアプリケーションのリソース・マネージャーとして機能 sparkのワーカー1 sparkのワーカー2 Sparkマスターに送信されたジョブの一部の実行を担当するエグゼキューターを起動 バージョン Python 3.7 Apache Spark 3.0.1 Apache Hadoop 3.2 Docker 20.10.6 docker-compose 1.29.1 ディレクトリ構成 spark-challenge . ├── build │ ├── master │ │ ├── Dockerfile │ │ └── files │ │ └── etc │ │ └── spark-defaults.conf │ └── worker │ └── Dockerfile ├── data │ └── bread_basket.csv ├── docker-compose.yaml ├── main.py └── scripts └── start.sh Dockerアプリ起動方法 spark-challengeディレクトリで、dockerコンテナ起動 $ cd spark-challenge $ docker-compose up -d ソースコード docker-compose.yaml docker version: '3.3' services: spark-master: build: context: ./build/master/ dockerfile: Dockerfile container_name: spark-master ports: - "8080:8080" - "7077:7077" - "4040:4040" - "18080:18080" volumes: - ./:/app environment: - INIT_DAEMON_STEP=setup_spark networks: - ichi_spark_network spark-worker-1: build: context: ./build/worker/ dockerfile: Dockerfile container_name: spark-worker-1 tty: true ports: - "8081:8081" volumes: - ./:/app environment: - SPARK_MASTER=spark://spark-master:7077 networks: - ichi_spark_network spark-worker-2: build: context: ./build/worker/ dockerfile: Dockerfile container_name: spark-worker-2 tty: true ports: - "8082:8081" volumes: - ./:/app environment: - SPARK_MASTER=spark://spark-master:7077 networks: - ichi_spark_network networks: ichi_spark_network: Dockerfile master用 FROM bde2020/spark-master:3.0.1-hadoop3.2 WORKDIR /app ENV LANG="ja_JP.utf8" \ LANGUAGE="ja_JP.utf8" \ LC_ALL="ja_JP.utf8" RUN apk --update add coreutils RUN apk add procps RUN rm -f /usr/bin/python \ && ln -s /usr/bin/python3.7 /usr/bin/python \ && pip3 install --upgrade pip RUN mkdir /tmp/spark-events COPY files/etc /etc RUN mv /etc/spark-defaults.conf /spark/conf worker用 FROM bde2020/spark-master:3.0.1-hadoop3.2 WORKDIR /app ENV LANG="ja_JP.utf8" \ LANGUAGE="ja_JP.utf8" \ LC_ALL="ja_JP.utf8" RUN apk --update add coreutils RUN apk add procps ※イメージは、こちらを使用しました =>bde2020/spark-master main.py main.py from pyspark import SparkConf, SparkContext from pyspark.sql import SparkSession from pyspark.sql.types import * from pyspark.sql.functions import * # SparkContextインスタンスを生成。SparkConfに書いた設定値を渡す。 conf = SparkConf().setAppName("simpleApp").setMaster("spark://spark-master:7077") sc = SparkContext(conf=conf) # SparkSessionのビルダーを使い、SparkSessionインスタンスを生成 spark = SparkSession.builder.config(conf=sc.getConf()).getOrCreate() # スキーマを指定 schema = StructType( [ # At the 3rd variable, set nullable or not StructField("Transaction", IntegerType(), True), StructField("Item", StringType(), True), StructField("date_time", StringType(), True), StructField("period_day", StringType(), True), StructField("weekday_weekend", StringType(), True) ] ) # Set spark.sql.legacy.timeParserPolicy to LEGACY to restore the behavior before Spark 3.0. # *Allow 'EEE MMM dd HH:mm:ss zzz yyyy' format pattern spark.sql("set spark.sql.legacy.timeParserPolicy=LEGACY") # データの読み込み csv_path = "./data/bread_basket.csv" csv_df = ( spark.read.option("header", True) .option("mode", "PERMISSIVE") .option("sep", r",") .option("enforceSchema", False) .schema(schema) .csv(csv_path) ) # データフレーム作成 # Convert date_time into timestamp type. add a column of format_date_time df = csv_df.withColumn("format_date_time", to_timestamp(col("date_time"), "dd-MM-yy HH:mm")) # テンプViewの作成 df.createOrReplaceTempView("BreadBasket") df.printSchema() # クエリの作成 query = f''' SELECT * FROM BreadBasket WHERE Item = 'Coffee' AND format_date_time BETWEEN '2016-11-01 00:00' AND '2016-12-01 00:00' LIMIT 10 ''' # データフレームにクエリ実行結果をセット df = spark.sql(query) # データフレームの表示 df.show() # spark.stop() spark.stop()の説明 SparkSessionインスタンスを生成すると、HTTPサーバーとしての機能が起動する。 終了するときはstopメソッドを呼び出す。 stopすることで、各executorも終了する。 このstopメソッドは、内部でSparkContextのstopを呼び出している。 補足情報 pyspark インストール $ pip install pyspark # ver 3.1.2 Kaggleからデータセットのダウンロード Group Byなんかもできる。 query = f''' SELECT Item, COUNT(*) AS item_count FROM BreadBasket GROUP BY Item ORDER BY item_count DESC ''' df.groupBy("Item").count().sort("count", ascending=False).show() マスターノードとワーカーノードを立ち上げる $ cd spark-challenge $ sh ./scripts/start.sh start.sh中身 start.sh #!/bin/bash docker exec -d spark-master /spark/sbin/start-history-server.sh docker exec -d spark-worker-1 /spark/sbin/start-slave.sh spark://spark-master:7077 docker exec -d spark-worker-2 /spark/sbin/start-slave.sh spark://spark-master:7077 Masterのコンテナに入りmain.pyの実行 $ docker exec -it spark-master bash $ /spark/bin/spark-submit /app/main.py http://localhost:8080/にアクセス！！ おおお〜GUI見れましたね！！ ワーカーさんが二人、 完了タスクが2つ　みたいになってますな。 http://localhost:18080/にアクセス！！ ポートが18080です！w 紛らわしいですね！w ヒストリーサーバーも立ち上がっているので、実行履歴の確認が可能です。 ※実行履歴画面があることに後で気づいたので、後付けのキャプチャになります。上記では2件のアプリ実行なのに、こっちでは1件となっていて齟齬があります汗 あまり気にしないでください〜?‍♀️ SparkがMesosあるいはYARN上で実行されている場合でも、アプリケーションのイベントログが存在するならSparkの履歴サーバを使って終了したアプリケーションのUIを構築することが可能です。以下を実行することで履歴サーバを開始することができます: ./sbin/start-history-server.sh これはデフォルトで http://:18080 にwebインタフェースを生成し、未完了あるいは完了済みのアプリケーションと試行をリスト化します。 参照元：監視および計測器 df.printSchema()の実行結果 root |-- Transaction: integer (nullable = true) |-- Item: string (nullable = true) |-- date_time: string (nullable = true) |-- period_day: string (nullable = true) |-- weekday_weekend: string (nullable = true) |-- format_date_time: timestamp (nullable = true) df.show()の実行結果 +-----------+------+----------------+----------+---------------+-------------------+ |Transaction| Item| date_time|period_day|weekday_weekend| format_date_time| +-----------+------+----------------+----------+---------------+-------------------+ | 178|Coffee|01-11-2016 07:51| morning| weekday|2016-11-01 07:51:00| | 179|Coffee|01-11-2016 08:20| morning| weekday|2016-11-01 08:20:00| | 188|Coffee|01-11-2016 10:04| morning| weekday|2016-11-01 10:04:00| | 189|Coffee|01-11-2016 10:29| morning| weekday|2016-11-01 10:29:00| | 190|Coffee|01-11-2016 10:34| morning| weekday|2016-11-01 10:34:00| | 193|Coffee|01-11-2016 11:00| morning| weekday|2016-11-01 11:00:00| | 197|Coffee|01-11-2016 11:10| morning| weekday|2016-11-01 11:10:00| | 197|Coffee|01-11-2016 11:10| morning| weekday|2016-11-01 11:10:00| | 198|Coffee|01-11-2016 11:11| morning| weekday|2016-11-01 11:11:00| | 199|Coffee|01-11-2016 11:13| morning| weekday|2016-11-01 11:13:00| +-----------+------+----------------+----------+---------------+-------------------+ やりましたね！ちゃんとcsvのデータセットが反映されて、無事クエリ結果が返ってきました！ ハマったポイント kaggleから落としてきたcsvファイルの名前が、bread basket.csvとなっていて、アンダースコアがなくて、ファイル読み込みで死んだ。うそやんw Dockerfileのln -s /usr/bin/python3.7 /usr/bin/pythonのコマンドところ コンテナ入ってみたら、pythonのversionが3.7になっていて、3.9とかに勝手に変えてしまったら、そんなファイルないよって怒られた ちゃんとそのイメージの中(今回で言うとbde2020/spark-master:3.0.1-hadoop3.2こやつ。)に何が含まれているか確認しないとダメですね yamlの拡張子は、ymlでもいいらしい。違いは３文字か４文字のどちらで表記するかだけ まとめと感想 apache sparkを初めて触って、Pysparkライブラリを使って色々いじる感じとその感覚が養えました！ もっともっとデータの処理であったり詳細の部分をこれから詰められればと思っています。 実務で経験積んでみたいな〜〜（´-`）.｡oO Python面白すぎてワクワクが止まりません〜?✨ 以上、ありがとうございました！

M1 Macでdocker-composeをするときにmysqlのインストールに失敗するとき。 Status: Downloaded newer image for nginx:latest Pulling db (mysql:5.7)... 5.7: Pulling from library/mysql ERROR: no matching manifest for linux/arm64/v8 in the manifest list entries このようなエラーが出る。 ERROR: no matching manifest for linux/arm64/v8 in the manifest list entries デフォルトでlinux/arm64/v8のmysqlを探しに行って見つからずにエラーを吐いているようだ。 対処法 docker-compose.ymlにplatformを指定して再度docker-composeをする。 db: image: mysql:5.7 platform: linux/x86_64 platform: linux/x86_64 をDBの箇所に指定してあげればエラー無くインストールが完了する。

こんにちは。まゆみです。 Dockerについての記事をシリーズで書いています 前回の記事に、『docker-compose』で2つ以上の独立したContainerをお互いにコミュニケーションを取らせ、情報をやり取りさせるにはどのようにしたらいいのかを書きました。 今回の記事では、docker-compose で使う主要なコマンドをまとめていきたいと思います 前回の記事に、docker-composeを使う時の手順や、YAMLファイルの書き方などは記載していますので、今回の記事では、docker-composeのコマンドのみに焦点をあてて書いていきます docker-composeのコマンド自体を見るコマンド docker-composeはどんなコマンドが使えるのかな？と docker-composeで使えるdockerのコマンドを見たい時のコマンドは docker-compose になります。 イメージをbuildする docker-compose でイメージをbuildする時は docker-compose build になります Docker CLIを使って、docker イメージをbuildする時には、 docker build <build context> と、build context名が必要でしたが、docker-compose でイメージをbuildする時には、＜build context＞を書く必要はありません。 なぜなら、YAMLファイルに書いてあるからです。 docker-compose up DockerCLIを使ってdockerを一つづつ実行するときは docker run <Image ID> でした。 Docker-composeを使って2つ以上のContainerを起動するには docker-compose up を用います。 docker-compose up についても、＜image ID ＞を指定しなくても大丈夫です。 理由は、先ほどの docker-compose build と同じく、YAMLファイルに書いてあるからです。 Dockerfileを更新した後にdocker-compose upするには？ Dockerfileの内容を書き換えたあと、そのあとまた『docker-compose up』で実行すると、 古い方のDockerfileが使われて実行されてしまいます。 新しいDockerfileの内容を反映させたい時は docker-compose up --build で実行します dockerをストップさせるには？ docker-compose up で起動したcontainer は docker-compose down でストップさせることができます Docker CLIでは、docker stop でストップさせても、 Container自体を消すことはできませんでしたが、 docker-compose down だと、 Containerを止めてさらに消すことまでやってくれます。 まとめ Docker CLIを使うのに慣れていたら、docker-composeのコマンドにも比較的すぐ慣れることができると思います。 今回の記事は短いですが、ここで締めくくらせていただきますね。

はじめに 2021/5/27 Amazon Elastic Container Service Anywhereが一般利用開始になりました? オンプレミス環境で AWS のサービスを使用してコンテナをデプロイするオプションとして、これまでも AWS Outposts 上で Amazon ECS を利用するという選択肢はありましたが、気軽に導入できるものではありませんでした。Amazon ECS Anywhere はユーザーが所有する任意のインフラ環境で、ECS のコントロールプレーンを利用して簡単にコンテナを実行することができる機能です。 詳細な利用手順は他の記事に譲るとして、ECS Anywhere がどのような仕組みで動いているのかや他クラウドの類似サービスと比較したときの違いなどについて書いていきたいと思います。 ざっくり理解する ECS Anywhere ECS Anywhere でコンテナを実行するために必要な環境や設定をざっくり説明していきます。 実行環境の準備 サポートされる OS は以下です。CPU のアーキテクチャは x86_64 と ARM64 をサポートしています。 CentOS 7, CentOS 8 RHEL 7 openSUSE Tumbleweed Ubuntu 18, Ubuntu 20 Debian 9, Debian 10 SUSE Enterprise Server 15 OS 要件を満たし、Amazon ECS のエンドポイントおよび AWS Systems Manager のエンドポイントと通信できる環境であれば、文字通りどこでも実行できます。ECS のエンドポイントとしては以下のドメインと通信します。 ecs-a-*.<region>.amazonaws.com ecs-t-*.<region>.amazonaws.com ecs.<region>.amazonaws.com ecs-a と ecs-t のエンドポイントについては PrivateLink に対応していないため、DirectConnect を使用して完全な閉域 NW 経由で実行することは現時点で難しそうです (Public VIF を利用している場合を除く)。 Docker のインストール 実行環境となるサーバー、仮想マシンには Docker がインストールされている必要があります。 SSM Agent のインストール 実行環境となるサーバー、仮想マシンに AWS Systems Manager の SSM Agent をインストールし、ハイブリットアクティベーションによりマネージドインスタンスとして登録する必要があります。マネージドインスタンスは Systems Manager に以前から存在する機能で、オンプレミスのマシンに SSM Agent をインストールし、アクティベーションコードを登録すると、AWS 上からマネージドインスタンス (プレフィックス「mi-」が付いたマシン) として管理できるようになります。 マネージドインスタンスを使用すると、オンプレミスのマシンに対してハイブリット環境用の IAM サービスロールを割り当てることができます。この IAM ロールを通じて提供される一時クレデンシャルを利用することで、Amazon ECS やその他の AWS サービスと通信できるようになるわけです。オンプレミス環境ごとにアクセスキーを発行して、定期的にローテーション、、、というような面倒でリスクのある作業は不要です。 参考 ECS Agent の起動 Amazon ECS コンテナエージェントをインストール、起動します。ECS Agent はマネージドインスタンスに割当られた IAM ロールの認証情報を利用して ECS のコントロールプレーンと接続します。これで ECS API 経由でコンテナを起動できるようになります。 長々と説明してしまいましたが、準備が面倒そうだなと感じましたか？ ECS で External インスタンスを登録する際に表示されるスクリプトを実行すると、Docker のインストール、SSM Agent のインストールとマネージドインスタンスの登録、ECS Agent の起動まで 1 発でセットアップしてくれるため、実はめちゃくちゃ簡単です。 これが ECS Anywhere だ!! セットアップが完了したらマネージドコンソール、CLI、使い慣れたデプロイツールなどからサービスやスタンドアロンタスクを起動できるようになります。これらのコンテナが NLB や RDS といった VPC 上のリソースと通信する必要がある場合は、Direct Connect または Site-to-Site VPN 接続が必要です。 利用料金 ECS Anywhere の利用料金として、External インスタンス 1 台ごとに1 時間あたり、$0.01025 かかります。External インスタンス＝登録するホスト環境なので、コンテナの台数ではありません。1 台あたり月約 800 円といったところでしょうか。 Systems Manager は基本的には無料で利用可能ですが、マネージドインスタンスのアドバンスドインスタンス層を使用する場合は料金が発生します。ECS Anywhere としては無料の標準インスタンス層で問題ありませんが、以下のケースではアドバンスドインスタンス層を利用する必要があります。 マネージドインスタンスの管理台数が1アカウント、リージョンで 1,000 台を超える場合 Session Manager でマネージインスタンスにリモート接続したい場合 アドバンスインスタンス層はインスタンスごとに 1 時間あたり $0.00695 かかります。1 台あたり月 500 円くらいです。 ECS Anywhere の利点とユースケース ECS Anywhere の製品ページには以下のような利点とユースケースが記載されています。 利点 フルマネージドなコントロールプレーン 自前でコンテナオーケストレーションの仕組みを構築、運用する必要がに オペレーションの統一 AWS でもオンプレミスでも、同じツールを用いて運用することができる ハイブリット対応 1つのクラスターで EC2, Fargate, External インスタンスを同じクラスター内に配置可能 ユースケース コンプライアンス & ビジネス要件 既存のオンプレミスワークロードのコンテナ化 エッジコンピューティング (低レイテンシーが要求されるワークロード) 既存の設備投資を活用 オンプレミスで実行しつつ追加容量はクラウドにバースト 注目すべきはオンプレミスにおけるコンテナワークロードに特化している点だと考えています。AWS としてマルチクラウドのユースケースは (現時点で) 謳っていません。これは他社とは異なる傾向です。 類似サービスとの違い Microsoft や Google Cloud もオンプレミスやクラウド環境でコンテナ化したアプリケーションを実行可能にする Azure Arc や Anthos といったサービスを提供しています。また AWS は 2021年にAmazon EKS Anywhere を提供予定です。これらのサービスは一見 ECS Anywhere と同じような機能を提供するようにも見えますが、根本的に異なる点が 2 つあります。 ECS Anywhere はフルマネージドコントロールプレーンである マルチクラウドで実行される Kubernetes を統合管理可能な Azure Arc enabled Kubernetes やオンプレミスおよびマルチクラウド環境で Google Kubernetes Engine を動作させることができる Anthos クラスタ は Kubernetes をベースとしている関係で、コントロールプレーンもユーザー環境で動作することになります。 例えば Anthos clusters on AWS の場合、ざっくりと以下のような構成になります。 ECS Anywhere の場合、AWS 上でフルマネージドされている ECS のコントロールプレーンを利用してコンテナをオーケストレーションできます。つまりユーザーは External インスタンス上でコンテナを稼働させることだけに集中できると言えます。 マルチクラウドで AWS サービスを展開することはできない 自明なことではあるのですが、ECS Anywhere 上では AWS のサービスを実行することはできません。Azure や Google Cloud は他社クラウドやハイブリット環境で動作する自社サービスを提供することで、クラウド間でのデータ移動を必要とせずにあらゆる環境で一貫性のあるエクスペリエンスを提供する方向性です。ECS Anywhere は前述のとおりオンプレミス環境でのコンテナワークロードの実行に特化しており、この点からも AWS は現時点でマルチクラウドには注力していない状況が伺えます。 Google Cloud は Anthos クラスタ上で動作する BigQuery Omni や Cloud Run for Anthos といったサービスをリリースしています。 Microsoft は先日の Microsoft Build 2021 で Azure App Service や Functions, Logic Apps, API Magement, Event Grid といった Azure サービスをどの Kubernetes 環境でも実行できるようにする Azure Arc enabled application services を発表しています。 現時点で ECS Anywhere でサポートされない機能 Service Load Balancing Service Discovery ECS Exec Capacity Provider UpdateContainerAgent API によるリモートでの ECS Agent アップデート AWS AppMesh との統合 一番大きいのはサービス負荷分散に対応していない点ではないでしょうか。サービス負荷分散は ELB といい感じに連携してタスク間でトラフィックを分散する機能です。サービスの作成、更新時に「ネットワーク、ロードバランシング、オートスケーリングの設定は、EXTERNAL 起動タイプでは使用できない」というメッセージが表示されます。 External インスタンスの IP アドレスとコンテナが使用するポートを手動で ELB に登録することはできますが、本番ワークロードでの Web サービスの実行は現実的ではありません。この点はドキュメントにも明確に記載されています。 引用 & 参考訳 Amazon ECS 外部インスタンスは、アウトバウンド トラフィックを生成したり、データを処理したりするアプリケーションを実行するために最適化されています。アプリケーションで Web サービスなどのインバウンド トラフィックが必要な場合、Elastic Load Balancing のサポートがないため、これらのワークロードをロードバランサーの背後に配置することがサポートされていないため、これらのワークロードの実行効率が低下します。 まとめ Amazon ECS Anywere のいいところ コントロールプレーンを一切管理せずに、コンテナをオーケストレーションできる 普段 AWS で使用しているものと同じツール群で運用できる これからに期待するところ Web サービスの実行には向かない ECS Anywhere が ELB をサポートしておらず、Service Load Balancing を利用できないため 現時点ではデータ処理系のアプリケーションの実行に最適化されている マルチクラウドを想定したサービスではない オンプレミスにおけるコンテナワークロードに特化 もちろん他クラウドの VM を External インスタンスとして登録してコンテナ実行することは可能 参考 以上です。 参考になれば幸いです。

エラーまでの経緯 先日、「Docker-Desktop」をインストールした際に、初歩の初歩である「docker run hello-world」コマンドでエラーが発生し、先に進めなくなってしまいました。 当時の自分と同じくパニックになった方や、自分への備忘録のためとして残しておきたいと思います。 エラーの内容 > docker run hello-world docker: error during connect: This error may indicate that the docker daemon is not running.: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.24/containers/create": open //./pipe/docker_engine: The system cannot find the file specified. 【原因】WSLの有効化がされていない 端的に自分の場合の原因は、「WSLが有効化されていないこと」でした。 お急ぎの方は下のリンクから参照ください。 WSLの有効化手順 WSL とは WSL とは「Windows Subsystem for Linux」の略称で、 大雑把に言えば「Windows上で動くLinux」のことのようです。 WSL有効化の手順 ①PowerShellでコマンド実行 WSLを有効化するためには PowerShell でコマンドを実行する必要があります。 「Ctrlキー」と「Rキー」を同時に押してください。 「名前(O):」のところに「powershell」と入力して OK を押します。 PowerShellの青い画面が開いたら、以下のコマンドを実行してください。 PS> dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart 続けて、以下のコマンドを実行してください。 PS> dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart ※ここでエラーが発生すると、バージョンがWSLに対応していない可能性があります。 こちらのサイトで確認をしてください。 WSL有効化の手順 ②最新のパッケージをダウンロード 以下のリンク先から最新のパッケージをダウンロードします。 ダウンロードしたら、パッケージをダブルクリックして実行してください。 x64 マシン用 WSL2 Linux カーネル更新プログラム パッケージ WSL有効化の手順 ③WSL2を既定のバージョンとして設定する PowerShellで以下のコマンドを実行してください。 PS> wsl --set-default-version 2 WSL有効化の手順 ④docker run hello-worldの実行 お気に入りのターミナルで以下のコマンドを実行してください。 > docker run hello-world `「Hello from Docker!」と表示されれば成功です！ その他の原因 「docker-users」というユーザがwindowsに登録されていないからという場合もあるようです。 参考サイトを併せて記載します Docker for WindowsをWindows10Proにインストールする おわりに Docker を入れるだけ入れてみようと考えたら、エラー対処に相当時間を食われました...。 しかもHello-World...。 落ち込んでいる暇があれば共有して同じ失敗を減らそうと考えて投稿させていただきました。 誰かの助けに少しでもなれば幸いです。 読んでいただき、ありがとうございました。 Twitter ( ITの虫 ) のフォローもぜひよろしくお願い致します。

経緯 先日、「Docker-Desktop」をインストールした際に、初歩の初歩である「docker run hello-world」コマンドでエラーが発生し、先に進めなくなってしまいました。 当時の自分と同じくパニックになった方や、自分への備忘録のためとして残しておきたいと思います。 エラーの内容 > docker run hello-world docker: error during connect: This error may indicate that the docker daemon is not running.: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.24/containers/create": open //./pipe/docker_engine: The system cannot find the file specified. 【原因】WSLの有効化がされていない 端的に自分の場合の原因は、「WSLが有効化されていないこと」でした。 お急ぎの方は下のリンクから参照ください。 WSLの有効化手順 WSL とは WSL とは「Windows Subsystem for Linux」の略称で、 大雑把に言えば「Windows上で動くLinux」のことのようです。 WSL有効化の手順 ①PowerShellでコマンド実行 WSLを有効化するためには PowerShell でコマンドを実行する必要があります。 「Ctrlキー」と「Rキー」を同時に押してください。 「名前(O):」のところに「powershell」と入力して OK を押します。 PowerShellの青い画面が開いたら、以下のコマンドを実行してください。 PS> dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart 続けて、以下のコマンドを実行してください。 PS> dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart ※ここでエラーが発生すると、バージョンがWSLに対応していない可能性があります。 こちらのサイトで確認をしてください。 WSL有効化の手順 ②最新のパッケージをダウンロード 以下のリンク先から最新のパッケージをダウンロードします。 ダウンロードしたら、パッケージをダブルクリックして実行してください。 x64 マシン用 WSL2 Linux カーネル更新プログラム パッケージ WSL有効化の手順 ③WSL2を既定のバージョンとして設定する PowerShellで以下のコマンドを実行してください。 PS> wsl --set-default-version 2 WSL有効化の手順 ④docker run hello-worldの実行 お気に入りのターミナルで以下のコマンドを実行してください。 > docker run hello-world `「Hello from Docker!」と表示されれば成功です！ その他の原因 「docker-users」というユーザがwindowsに登録されていないからという場合もあるようです。 参考サイトを併せて記載します Docker for WindowsをWindows10Proにインストールする おわりに Docker を入れるだけ入れてみようと考えたら、エラー対処に相当時間を食われました...。 しかもHello-World...。 落ち込んでいる暇があれば共有して同じ失敗を減らそうと考えて投稿させていただきました。 誰かの助けに少しでもなれば幸いです。 読んでいただき、ありがとうございました。 Twitter ( ITの虫 ) のフォローもぜひよろしくお願い致します。 参考文献 Windows 10 用 Windows Subsystem for Linux のインストール ガイド

私にはまだDockerなんてものは早いと思ったんですが、rbenvの設定が全然出来ず、「これはDockerでやったほうが早いわ！」と思って作成。 山浦先生のほぼ丸パクリです。よくわかんない人は見るべき。本当に分かりやすかったです。 本番環境には入れない予定。あくまで忘備録です。 先にメモ Dockerfileとdocker-composeはGemfileとかと同じ位置に配置 Gemfile sqliteからmysql2へ Dockerfile Dockerfile FROM ruby:2.7 # 追記 ENV RAILS_ENV=production # 必要なライブラリのNode.jsとyarnをインストールしている RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list \ && apt-get update -qq \ && apt-get install -y nodejs yarn WORKDIR /app COPY . /app RUN gem install bundler:1.17.2 && bundle update --bundler RUN bundle config --local set path 'vendor/bundle' \ && bundle install # 以下追記 COPY start.sh /start.sh RUN chmod 744 /start.sh CMD ["sh", "/start.sh"] docker-compose.yml docker-compose.yml version: '3' # 2つのサービス(dbとweb)を定義する services: db: image: mysql:8.0 # mysqlの8.0から認証形式が変わったのでその設定 command: --default-authentication-plugin=mysql_native_password volumes: # ローカル:Dockerでsqlのデータを同期する設定 # コンテナを削除してもデータを引継ぎが出来る - ./db/mysql_data:/var/lib/mysql # 環境変数の設定 environment: # mysqlはパスワードが無いとエラーになるので設定 MYSQL_ROOT_PASSWORD: password # webというサービスがrailsを示している web: # 参照先 build: . # rails s でポートは3000、バインドはどこでもOKと設定 command: bundle exec rails s -p 3000 -b '0.0.0.0' # 同期設定 volumes: - .:/app ports: - "3000:3000" # webサービスはdbサービスに"依存"しているという記述 # これを記述するとIPアドレスを指定せずdbと書けば接続出来る depends_on: - db database.yml config/database.yml default: &default adapter: mysql2 encoding: utf8mb4 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> username: root password: password host: db development: <<: *default database: app_development test: <<: *default database: app_test host: <%= ENV.fetch("APP_DATABASE_HOST") { 'db' } %> production: <<: *default database: <%= ENV['APP_DATABASE'] %> username: <%= ENV['APP_DATABASE_USERNAME'] %> password: <%= ENV['APP_DATABASE_PASSWORD'] %> host: <%= ENV['APP_DATABASE_HOST'] %> start.sh start.sh #! /bin/sh # Dockerfileで普通はif分岐しないのでシェルスクリプトで対応 if [ "${RAILS_ENV}" = "production" ] then bundle exec rails assets:precompile fi # PORTの値が無ければ3000を代入する bundle exec rails s -p ${PORT:-3000} -b 0.0.0.0 .gitignore .gitignore # 追記 .env /db/mysql_data/* いよいよ開始！ sudoコマンドかdockerグループを作成すべし。 ubuntu(WSL2) $ docker-compose run web bundle exec rails new . --force --skip-bundle $ docker-compose build $ docker-compose run web rails db:create $ docker-compose run web rails db:migrate $ docker-compose up -d localhost:3000に接続して開発環境の設定おわり！いやはや簡単だ～ Containerを閉じる docker-compose downでコンテナの活動を止めて、docker system prune -aで使っていないコンテナを削除。 Dockerのアプリからも出来るからすごいなーと思ってます。 事前準備段階で上手くいかない linuxをWSL1からWSL2に変更 Docker Desktopのアップデート これが終わってからDocker Desktopの設定変更にとりかかる Finish! 間違っていたら教えてください！

この記事の執筆時点で、Vue 3 に対応した Vuetify はまだアルファ版です。 https://vuetifyjs.com/ja/introduction/roadmap/ リリース目標は 2021 年の Q3 らしいですが、待ちきれないので、現時点で公開されているアルファ版を入れてみました。 単純に add するだけ すでに vue-cli で Vue 3 のプロジェクトがある前提で、次のコマンドを実行します。 $ docker-compose run vue vue add vuetify ちなみに、上記コマンドの意味は「docker-compose.yml でサービス名が『vue』と定義されたコンテナに『vue add vuetify』というコマンドを実行させる」です。 （なので「vue vue」と重複しているのは typo ではありません） 実行すると「どの vuetify を入れるんだよ?」と聞かれるので「V3 (alpha)」を選択します。 すると、、、 ? Choose a preset: V3 (alpha) ? Invoking generator for vue-cli-plugin-vuetify... ? Installing additional dependencies... added 3 packages in 8s ⚓ Running completion hooks... ✔ Successfully invoked generator for plugin: vue-cli-plugin-vuetify vuetify Discord community: https://community.vuetifyjs.com vuetify Github: https://github.com/vuetifyjs/vuetify vuetify Support Vuetify: https://github.com/sponsors/johnleider ……と追加完了します。 確認 package.json を確認すると、vuetify 3 のアルファ版が追加されています。 package.json "dependencies": { "@mdi/font": "5.9.55", "core-js": "^3.6.5", "roboto-fontface": "*", "vue": "^3.0.0", "vue-router": "^4.0.0-0", "vuetify": "^3.0.0-alpha.0", // ←追加されてる "vuex": "^4.0.0-0" }, それから、ちょいちょいファイルが書き変わってますね。 こんな感じで。 main.js import { createApp } from 'vue' import vuetify from './plugins/vuetify' // ←追加 import App from './App.vue' import router from './router' import store from './store' const app = createApp(App) app.use(router) app.use(store) app.use(vuetify) // ←追加 app.mount('#app') うーん、それにしても、入れたはいいが使い方がよく分からん?