目的 2022年さらに活用できるための備忘メモ用 年内のおさらい 技術メモまとめ 試したこと 1. Docker MatterMost をここでは題材にしています。 git clone https://github.com/mattermost/mattermost-docker-preview.git Dockerfile # Copyright (c) 2016-present Mattermost, Inc. All Rights Reserved. # See License.txt for license information. FROM mysql:5.7 RUN apt-get update && apt-get install -y ca-certificates # # Configure SQL # ENV MYSQL_ROOT_PASSWORD=mostest ENV MYSQL_USER=mmuser ENV MYSQL_PASSWORD=mostest ENV MYSQL_DATABASE=mattermost_test # # Configure Mattermost # WORKDIR /mm # Copy over files ADD https://releases.mattermost.com/6.0.0/mattermost-team-6.0.0-linux-amd64.tar.gz . RUN tar -zxvf mattermost-team-*-linux-amd64.tar.gz ADD config_docker.json ./mattermost/config/config_docker.json ADD docker-entry.sh . RUN chmod +x ./docker-entry.sh ENTRYPOINT ./docker-entry.sh # Mattermost environment variables ENV PATH="/mm/mattermost/bin:${PATH}" # Create default storage directory RUN mkdir ./mattermost-data VOLUME /mm/mattermost-data # Ports EXPOSE 8065 dockerがインストール済みであれば、以下コマンドで起動完了 docker run --name mattermost-preview -d --publish 8065:8065 mattermost/mattermost-preview 2. VBA Do Until 文を極めれば、いろいろツールが作れる Dim row As Integer row = 2 Do Until Cells(row, 1).Value = "" Cells(row, 5).Value = Cells(row, 3).Value * Cells(row, 4).Value row = row + 1 Loop No列は固定となるので、それを軸にすることで、楽にツール化できる。 3. JsRender.js Reactを使わない環境では、JqueryやNode.jsと共に使われるケースが多い。 https://www.jsviews.com/ 読み込みに必要なもの <!-- Load jQuery --> <script src="https://code.jquery.com/jquery-3.5.1.js"></script> <!-- Load JsRender latest version, from www.jsviews.com: --> <script src="https://www.jsviews.com/download/jsrender.js"></script> 実装サンプル <!-- １．レンダリングされる最終的な箱の用意 --> <div id="result"></div> <!-- ２．レンダリング情報の宣言 --> <script id="myTmpl" type="text/x-jsrender">{{:name}}</script> <!-- ３．具体的なJSの中身 --> <script> var tmpl = $.templates("#myTmpl"); var data = {name: "Jo"}; var html = tmpl.render(data); // テンプレート（tmp1)にデータがレンダリングされる $("#result").html(html); // ←ここで初めて「１」のDOMに出力される </script> 4. React.js と Webpack そもそもReact.jsってなんだよ？ ググるといろいろ出てきますが、一言でいうと「古DOMと新DOMの差分から、更新したいDOMだけを見極めて、ブラウザにレンダリング情報をセクションとしてコンポーネント単位等でDOMに流し込むことができる。」 Reactインストール $ npm install react react-dom $ npm install -D @babel/preset-react node.js って npm とは Node Package Manager の略。 JavaScript 系のパッケージを管理するツール。 必要とするパッケージをインストールする際、依存するパッケージもまとめてインストールしてくれる。 node.jsの初期編としては、まず... npm init などで作成したpackage.jsonを基準に、npm installを実施して、node_moduleのディレクトリ作成される。 package.josn { "name": "myProject", "version": "1.0.0", "description": "", "main": "index.js", //←エントリポイント "scripts": { "test": "echo \"Error: no test specified\" && exit 1", "build”: "webpack --mode production", "dev”: "webpack --watch", }, "keywords": [], "author": "", "license": "ISC" } webpack 複数のモジュールを1つにまとめて出力できる。モジュールバンドラ。 loderを用いることでjsファイル以外をまとめることができる。 Webpack インストール $ npm install -D webpack webpack-cli webpack-dev-server html-webpack-plugin Babelインストール $ npm install -D @babel/core @babel/runtime @babel/plugin-transform-runtime @babel/preset-env babel-loader Babel本体とプラグイン、プリセットの設定、webpackのローダーをインストール。 TypeScriptを使用する $ npm install -D typescript ts-loader @babel/preset-typescript @types/react @types/react-dom tsconfig.json { "compilerOptions": { "target": "esnext", "jsx": "react", "forceConsistentCasingInFileNames": true, "strict": true, "noImplicitAny": true, "strictNullChecks": true, "noUnusedLocals": true, "noUnusedParameters": true, "noImplicitReturns": true, "moduleResolution": "node", "esModuleInterop": true, "isolatedModules": true, "allowSyntheticDefaultImports": true, }, "include": ["src/**/*.ts", "src/**/*.tsx"], "exclude": ["node_modules"] } ビルド $ npm run build $ webpack --watch ←WATCHモードとはビルド対象のファイルに変化があった場合に検知して、自動的に再ビルドしてくれる機能のことです。（一言でいうと修正してすぐ反映） ビルド&実行 $ npx webpack serve --config webpack.config.js webpack.config.js const path = require("path"); const HtmlWebpackPlugin = require("html-webpack-plugin"); module.exports = { mode: "development", entry: path.resolve(__dirname, "src/app.tsx"), // エントリーポイント修正 output: { path: path.resolve(__dirname, "dist"), filename: "app.js", }, resolve: { modules: [path.resolve(__dirname, "node_modules")], extensions: [".js", ".ts", ".tsx"], // ts, tsx 追加 }, module: { rules: [ { test: [/\.ts$/, /\.tsx$/], use: [ { loader: "babel-loader", options: { presets: ["@babel/preset-env", "@babel/preset-react", "@babel/preset-typescript"], // typescript追加 }, }, 'ts-loader' // ts-loader追加 ], }, ], }, plugins: [ new HtmlWebpackPlugin({ template: path.resolve(__dirname, "src/index.html"), }), ], }; JSのテストツール JEST などでテストメソッドを作成し、検証ができる。 ５. Spring と Junit Spring の話は略します Junit ValidationTest1.java @ParameterizedTest @ValueSource(strings = {"Java", "java", "JAVA"}) void upperCase(String s) { assertEquals("JAVA", s.toUpperCase()); } SampleTest1.java @Test public void testJudgeGrade() { System.out.println("judgeGrade"); int score = 0; Score instance = new Score(); String expResult = ""; String result = instance.judgeGrade(score); assertEquals(expResult, result); // TODO review the generated test code and remove the default call to fail. fail("The test case is a prototype."); } Mockito Mockitoは、Javaのユニットテストのために開発されたモックフレームワーク（mocking framework）です。テストでモックオブジェクトを直感的に操作できるのを目的として開発されています。 モックオブジェクトはテスト対象（テストしたいクラス）から呼び出される依存先のオブジェクトに代わって使用されるテスト用のオブジェクトです。 スタブ メソッドの実行に対して、事前に定義された振る舞い（引数、返り値）を提供するオブジェクト モック メソッドの実行に対して、実行回数やパラメータの呼び出しを記録するオブジェクトです。 スパイ メソッドの実行に対して、実行回数やパラメータの呼び出しを記録するオブジェクトです。モックとの違いとして、基本的な定義では、モックはメソッドの実行中に検証するのに対して、スパイはメソッドの実行後に検証するという違いがあります。しかし、Mockitoで扱う検証メソッドではメソッドの実行後に検証するので両者の違いはありませんが、Mockitoにおけるスパイはオブジェクトを部分的にモックする用途で使用されています。 使用方法 テスト対象のクラスに @InjectMocks をつける テスト対象のクラス内で呼ばれるクラスに @Mock をつける 前処理(@BeforeEach)に、@Mock のモックオブジェクトを初期化する XxxYyyyServiceTest.java @Before public void init() { //@Mockアノテーションのモックオブジェクトを初期化 //これを実行しないと@Mockアノテーション、@InjectMocksを付与した //Mockオブジェクトが利用できない MockitoAnnotations.initMocks(this); //Mockの設定 //mapper.findAll()メソッドを実行した際の戻り値をここで設定 when(mapper.findAll()).thenReturn(makeUserDataList()); } @Test をつけたメソッド内でInjectMocksした(テスト対象メソッド)を実行する assertEquals 等でモックの結果と期待結果を比較 最後に 2022年は、自身の強みをさらに伸ばして、かつできなかったところを総復習し、 案件で活躍していきたいですね。良いお年を...

エラー内容 docker-compose up時に以下のエラーが発生しました。 [error] failed to initialize database, got error dial tcp 172.19.0.2:3306: connect: connection refused 原因 docker-composeでcontainer_nameを指定していなかったため 対処法 Before docker-compose.yml version: "3.9" services: backend: build: . ports: - 8000:8000 volumes: - .:/app depends_on: - db db: image: mysql:5.7.22 restart: always environment: MYSQL_DATABASE: ambassador MYSQL_USER: root MYSQL_PASSWORD: root MYSQL_ROOT_PASSWORD: root volumes: - .dbdata:/var/lib/mysql ports: - 33066:3306 main.go var DB *gorm.DB func Connect() { var err error DB, err = gorm.Open(mysql.Open("root:root@tcp(db:3306)/ambassador"), &gorm.Config{}) if err != nil { panic("Could not connect with database!") } } After docker-compose.yml container_name: godockerDBを追加 version: "3.9" services: backend: build: . ports: - 8000:8000 volumes: - .:/app depends_on: - db db: image: mysql:5.7.22 container_name: godockerDB # 追加 restart: always environment: MYSQL_DATABASE: ambassador MYSQL_USER: root MYSQL_PASSWORD: root MYSQL_ROOT_PASSWORD: root volumes: - .dbdata:/var/lib/mysql ports: - 33066:3306 main.go godockerDBを指定 var DB *gorm.DB func Connect() { var err error # container_nameを指定 DB, err = gorm.Open(mysql.Open("root:root@tcp(godockerDB)/ambassador"), &gorm.Config{}) if err != nil { panic("Could not connect with database!") } } 参考

やりたいこと Jenkins でビルド・デプロイ後に Cypress で E2E テストを実施したい ビルド・デプロイジョブの後に呼び出せる E2E テスト実行ジョブを作りたい E2E テストは github で管理したい 開発環境をいじるのが嫌だったので、ローカルでいろいろお試し。 環境 WSL2 Ubuntu 20.04 前提 github 上に Cypress E2E プロジェクトを用意している Jenkins の設定 Docker で Jenkins を起動するための Dockerfile と docker-compose.yaml FROM jenkins/jenkins:latest USER root RUN apt-get update \ && apt-get install -y \ nodejs \ # Cypress 実行のために必要なパッケージ↓ npm \ libgtk2.0-0 \ libgtk-3-0 \ libgbm-dev \ libnotify-dev \ libgconf-2-4 \ libnss3 \ libxss1 \ libasound2 \ libxtst6 \ xauth \ xvfb USER jenkins docker-compose.yaml version: "3" services: jenkins: container_name: jenkins build: . ports: - 8080:8080 volumes: - ./jenkins_home:/var/jenkins_home environment: - NO_COLOR=1 # Cypress の実行結果が文字化けするため - JAVA_OPTS=-Duser.timezone=Asia/Tokyo -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 初回起動 docker-compose up で起動 Docker 上で Jenkins の起動が完了したら http://localhost:8080 にアクセス 初回起動時は Administrator password の入力が必要 初期パスワードは /var/jenkins_home/secrets/initialAdminPassword に記載されている そのまま初期設定完了まで進む github 認証 Jenkins の管理 ⇒ Manage Credentials ⇒ Jenkins ⇒ グローバルドメイン Add Credentials github の認証情報を追加する ユーザー名：github アカウント パスワード：github の Access Token ID：github（自分で分かりやすいもの） ジョブ作成 新規ジョブ作成 ⇒ パイプライン Pipeline script 作成 pipeline { agent any stages { stage('cypress test') { steps { git credentialsId: 'github', url: 'https://github.com/xxx/cypresse2e.git' // credentialsId は上で作成した github 認証の ID sh 'npm install cypress --save-dev' sh 'npx cypress run' } } } } E2E テスト実行 作成したジョブの ビルド実行 はまったところ jenkins_home のアクセス権限 docker-compose up した際に、作業ディレクトリに jenkins_home が作成される。何回か試していた際に、このディレクトリにアクセスできないエラーが発生した。 一回削除して、同名のディレクトリを作成したらエラーが解消。（実行ユーザーの問題？） Cypress 実行結果の文字化け Jenkins の Console Output に Cypress の実行結果が出力される。ここが盛大に文字化けしていた。 どうやら Cypress の実行結果は ANSI で出力され、Jenkins 側が対応していない模様。（プラグインを入れれば OK？) NO_COLOR=1 を設定することで文字化けが解消される。 https://docs.cypress.io/guides/continuous-integration/introduction#Colors 参考 https://hub.docker.com/_/jenkins https://dev.classmethod.jp/articles/jenkins-on-docker/ CI with Jenkins build pipeline for Cypress automation testing：https://www.youtube.com/watch?v=UFErY92HeyM

ここまで使ったコマンドまとめ この連載では、現在 Xampp を使って構築されている開発環境を Docker 環境に移築することを目標に、Docker Desktop の導入から、複数のコンテナに（ポート指定ではなく）URL でアクセスするテストを行ってきました。 今回は、今まで使ったコマンドをいったんまとめておきます。 詳しくは Docker-Docks-ja Docker コマンド 参照してください。 docker build $ docker build --tag bulletinboard:1.0 . サンプルの掲示板を作るときに使ったコマンドです。 1. --tag bulletinboard:1.0 は、name:tag 形式でイメージの名前とオプションのタグを指定します 2. 最後の「.」はイメージを構築するのに必要なファイル（Dockerfile, それ以外のファイル = context）が置かれた場所で、今回の例では Dockerfile などがあるディレクトリに移動して実行してからコマンド実行しているので「.」になっています。 さて、docker build といえば、Dockerfile も避けては通れないところ。なのですが、頼みの綱の Docker-Docks-ja Dockerfile リファレンス を見ても、どう書けばいいのかさっぱりわかりません。 これはもう少し修行を積んでから再アタックする必要がありそうです。 docker run $ docker run --publish 8000:8080 --detach --name bb bulletinboard:1.0 --publish 8000:8080 これは以前も書いたけど、localhost:8000 へのリクエストを起動したコンテナの 8080 番へ渡す、という指定 --detach はコンテナをバックグラウンドで実行。起動に成功するとコンテナ ID を表示して終了する。起動後、シェルでアクセスしたときなどは -it --name bb はコンテナに bb という名前を付ける bulletinboard:1.0 は起動するイメージを name:tag 形式で指定 これでコンテナの起動はできました。起動したコンテナの確認は終了は ps, kill を使います。 docker ps, docker kill, docker start $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f4e8523b239f bulletinboard:1.1 "docker-entrypoint.s…" 3 hours ago Up 3 hours 0.0.0.0:8001->8080/tcp bb1 400310f54ff6 bulletinboard:1.0 "docker-entrypoint.s…" 5 hours ago Up 5 hours 0.0.0.0:8000->8080/tcp bb $ docker kill 400 400 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f4e8523b239f bulletinboard:1.1 "docker-entrypoint.s…" 3 hours ago Up 3 hours 0.0.0.0:8001->8080/tcp bb1 6d224cd173a5 vm_mysql "docker-entrypoint.s…" 44 hours ago Up 44 hours 33060/tcp, 0.0.0.0:13306->3306/tcp vm_mysql_1 docker ps -a とすれば、起動していないコンテナも表示されます。 ps で終了したいコンテナの ID を取得して kill で ID を指定。 ID はすべて書く必要はなく、上の例なら docker kill 4 だけでも OK 。 では kill したコンテナを再起動したときは？　もう一度 run コマンドを実行すると $ docker run --publish 8000:8080 --detach --name bb bulletinboard:1.0 docker: Error response from daemon: Conflict. The container name "/bb" is already in use by container "400310f54ff66965cabb56d0e1cd65414f076b83b08edf1ee8ab7f4615ec934a". You have to remove (or rename) that container to be able to reuse that name. See 'docker run --help'. 同じ名前は使えない、と怒られます。 docker run は「create(コンテナの作成)」＋「start(コンテナの実行)」なので、一度 run で作ったものは start で起動できます。 $ docker start bb bb は 4 (コンテナ ID 数文字)でも大丈夫。 docker exec 連載記事中には出てきてませんが、実際に使うことの多いコマンド。 起動中のコンテナに入るのに使います $ docker exec -it 400 bash root@400310f54ff6:/usr/src/app# ls -al total 116 drwxr-xr-x 1 root root 4096 Dec 30 00:35 . drwxr-xr-x 1 root root 4096 Dec 30 00:35 .. -rwxr-xr-x 1 root root 22 Mar 8 2021 .gitignore -rwxr-xr-x 1 root root 127 Mar 8 2021 Dockerfile -rwxr-xr-x 1 root root 1131 Mar 8 2021 LICENSE -rwxr-xr-x 1 root root 1239 Mar 8 2021 app.js drwxr-xr-x 2 root root 4096 Dec 30 00:35 backend drwxr-xr-x 3 root root 4096 Sep 19 08:04 fonts -rwxr-xr-x 1 root root 1826 Mar 8 2021 index.html drwxr-xr-x 91 root root 4096 Dec 30 00:35 node_modules -rw-r--r-- 1 root root 57138 Dec 30 00:35 package-lock.json -rwxr-xr-x 1 root root 572 Mar 8 2021 package.json -rwxr-xr-x 1 root root 888 Mar 8 2021 readme.md -rwxr-xr-x 1 root root 1071 Mar 8 2021 server.js -rwxr-xr-x 1 root root 1227 Mar 8 2021 site.css root@400310f54ff6:/usr/src/app# exit exit 今回で導入編は完了。 次回以降では、docker-compose を使って実際に LAMP 環境を構築していきます。 参考URL とほほのDocker入門 90年代から続く、技術系老舗サイト。 杜甫々さんは何歳なんだろう。お世話になってます。 Docker で LAMP 環境を作ろう　第 1 回 Docker で LAMP 環境を作ろう　第 2 回 Docker で LAMP 環境を作ろう　第 3 回

前回までのあらすじ サンプルのコンテナをダウンロードしてイメージを作成、起動。その後 hosts ファイルへの記述追加と netsh コマンドを使って、構築したコンテナにドメイン名でアクセスできるようにしました。 ただし 192.168.***.*** www.bulletin-board.internal 192.168.***.*** www2.bulletin-board.internal のように、同じ IP アドレスに別名をつけても、http://www2.bulletin-board.internal で同じページが表示されてしまい、これでは目的が達せられないよね、というところで終わっています。 今回は、この点を何とかしてみましょう。 複数の IP アドレスを用意する 私の環境は Windows10 なので、タスクバー右端のネットワークのアイコンを右クリックして [ネットワークとインターネットの設定を開く] を選んで、順次 [ネットワークと共有センター] → [イーサネット] → [プロパティ] → [インターネット プロトコル バージョン4(TCP/PIv4) ] → [プロパティ] → [詳細設定(V)] と進み、 [追加] から適当な IP アドレスを追加してやればいいのですが、 ・なかなか深いところにある ・複数の IP アドレスを一気に入力できない ことから、なかなか面倒です。 こんなときは、前回もお世話になっている Windows PowerShell を管理者権限で開き、 netsh interface ip add address name="イーサネット" addr=192.168.xxx.xxx mask=255.255.255.0 等とすることで追加できます。 「イーサネット」の部分は「ローカル エリア接続」の人もいるかもしれません。 うまく追加できないときは ipconfig で確認してみてください。 さて、こんな感じで、私の環境では 192.168.xxx.1 ～ 5 まで追加しました。 hosts とプロキシ設定の変更 さて、次は作った IP アドレスにドメインを紐づけます。 前回は www.bulletin-board.internal としましたが、長いので www.bb.internal にしちゃいます。 192.168.***.1 www.bb.internal 192.168.***.2 www2.bb.internal 前回セットしたプロキシもいったん削除し、新たに付け替えます。 PS C:\Windows\system32> netsh interface portproxy delete v4tov4 listenport=80 listenaddr=www.bulletin-board.internal PS C:\Windows\system32> netsh interface portproxy add v4tov4 listenport=80 listenaddr=www.bb.internal connectport=8000 connectaddress=127.0.0.1 PS C:\Windows\system32> netsh interface portproxy show all ipv4 をリッスンする: ipv4 に接続する: Address Port Address Port --------------- ---------- --------------- ---------- www.bb.internal 80 127.0.0.1 8000 PS C:\Windows\system32> ping www.bb.internal www.bb.internal [192.168.xxx.1]に ping を送信しています 32 バイトのデータ: 192.168.xxx.1 からの応答: バイト数 =32 時間 <1ms TTL=128 192.168.xxx.1 からの応答: バイト数 =32 時間 <1ms TTL=128 192.168.xxx.1 からの応答: バイト数 =32 時間 <1ms TTL=128 192.168.xxx.1 からの応答: バイト数 =32 時間 <1ms TTL=128 192.168.xxx.1 の ping 統計: パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、 ラウンド トリップの概算時間 (ミリ秒): 最小 = 0ms、最大 = 0ms、平均 = 0ms 正しく設定できているようです。 動作検証 まずは www.bb.internal にアクセスしてみます。 こちらは成功、www2.bb.internal にアクセスすると ということで、前回は見えてしまったものが見えなくなっています。 ついでにもうひとつコンテナを起動してみます。 D:\vm\node-bulletin-board\bulletin-board-app をコピーして D:\vm\nbb\bba を作成、起動します。 ただしこのままでは見た目の区別がつかないので、ちょっとだけ変更します。 site.css の 12 行目を変更して背景色を変更、 background-color: rgb(98, 145, 41); ついでに index.html の h1 も変えておきます。 <h1>Welcome to the Bulletin Board2</h1> この状態で起動し、http://localhost:8001/ にアクセスします。 $ docker build --tag bulletinboard:1.1 . [+] Building 2.2s (11/11) FINISHED => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 164B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/node:current-slim 1.9s => [auth] library/node:pull token for registry-1.docker.io 0.0s => [1/5] FROM docker.io/library/node:current-slim@sha256:8f8a97163bed5b292bcd7a92a96849ef7a4c1fc2b105b5579dff258307de25fe 0.0s => [internal] load build context 0.0s => => transferring context: 655B 0.0s => CACHED [2/5] WORKDIR /usr/src/app 0.0s => CACHED [3/5] COPY package.json . 0.0s => CACHED [4/5] RUN npm install 0.0s => [5/5] COPY . . 0.1s => exporting to image 0.1s => => exporting layers 0.0s => => writing image sha256:777db44bd53c96fa547d958a6680af6a816a81b23f3b27fab3d4c1c43fc6216d 0.0s => => naming to docker.io/library/bulletinboard:1.1 0.0s Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them $ docker run --publish 8001:8080 --detach --name bb1 bulletinboard:1.1 fea5584bcdc5265510e98b3c7e47f4935efafc647badd025a3eac4a0f10a24a3 こちらも無事起動できました。 では最後の仕上げ、www2.bb.internal に localhost:8001 を割り当ててアクセスしてみます。 PS C:\Windows\system32> netsh interface portproxy add v4tov4 listenport=80 listenaddr=www2.bb.internal connectport=8001 connectaddress=127.0.0.1 PS C:\Windows\system32> netsh interface portproxy show all ipv4 をリッスンする: ipv4 に接続する: Address Port Address Port --------------- ---------- --------------- ---------- www.bb.internal 80 127.0.0.1 8000 www2.bb.internal 80 127.0.0.1 8001 成功です。 参考 URL Network Shell (netsh) 普段あまり使わないけど知ってると便利な netsh コマンド（前回と一緒）。 Docker で LAMP 環境を作ろう　第 1 回 Docker で LAMP 環境を作ろう　第 2 回 Docker で LAMP 環境を作ろう　第 3 回

フォルダ構成は以下のような感じ。 docker環境を構築 docker-compose.yaml version: '3' services: php: build: ./php-apache/ volumes: - ./php.ini:/usr/local/etc/php/php.ini - ./html:/var/www/html ports: - 8080:80 xdebugとnodeとnpmをインストールする。 dockerfile FROM php:7.3-apache # Xdebugのインストール RUN pecl install xdebug-2.9.8 \ && docker-php-ext-enable xdebug RUN apt-get -y update RUN apt-get install -y \ curl \ gnupg # nodeのインストール RUN curl -fsSL https://deb.nodesource.com/setup_17.x | bash - && \ apt-get install nodejs # npmのインストール RUN npm install npm@latest -g gitでコマンドを打っています。ビルドする。 $ docker-compose build コンテナを起動する。 $ docker-compose up -d コンテナに入る。 $ docker container exec -it docker_php_1 bash tsconfig.jsonを生成する。 $ npx tsc --init tsconfig.jsonの設定。 tsconfig.json "target": "es6", "module": "commonjs", "sourceMap": true, "outDir": "./dist/", "rootDir": "./src/", "noEmitOnError": true, "strict": true, "esModuleInterop": true, "experimentalDecorators": true, "forceConsistentCasingInFileNames": true typescriptソース。 /src/index.ts function sayHello(): void { console.log('Hello!'); } console.log(sayHello()); vscodeのデバッグ設定。 lanch.json "version": "0.2.0", "configurations": [ { "type": "pwa-chrome", "request": "launch", "name": "debug typescript", "url": "http://localhost:8080/section9-setup/", "webRoot": "${workspaceFolder}", } ] typescriptファイルをコンパイルする。 (index.jsとindex.js.mapが生成される) $ npx tsc index.htmlの記述。 index.html <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta http-equiv="X-UA-Compatible" content="ie=edge"> <title>Document</title> <script src="./dist/index.js"></script> </head> </html> index.tsにブレークポイントを置く。デバッグするとブレークポイントで停止した。 (補足)ちなみにブラウザも立ち上がる。

はじめに 通常使用には困らないですが、自分が気がついた差異について書いていきます。 ｇVisor(runsc)が入れられない もっと良い資料があるかもしれないですが、ここの4ページ目に記載してある通りrootless dockerはruncをroot lessで動かす仕組みです。一方gVisorはruncをrunscに置き換えて実行する仕組みです。なので対応してないです。 自分が知っている中で関係あるのはGolangのPlaygroundとなります。他にもGKEなどでも使用されていますが、ローカルの開発環境に入れるわけではないのであまり関係ないです。 おわりに 本当は2つ書くつもりで書き始めたんですが、片方自分の勘違いだったことが判明したので超絶短い記事になってしまいました。。。

メモリ、CPU、GPU に対する実行時オプションの記載を参考にしています。 以下のようにdockerを利用する際、 docker run -p 6080:80 --shm-size=512m seigott/tetris_docker:latest 1GB memory, 1GB swap, 1CPUに制約する場合は、-memory="1g" --memory-swap="1g" --cpus="1"を指定すればよさそう docker run -p 6080:80 --memory="1g" --memory-swap="1g" --cpus="1" --shm-size=512m seigott/tetris_docker:latest 動作確認がそこまでできているわけではないが、、 参考 メモリ、CPU、GPU に対する実行時オプション

dockerコンテナ内などでqtを使用したアプリ使用時に以下のようなエラーが出る。 $ python test.py qt.qpa.xcb: could not connect to display qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb. Aborted 以下のように仮想的なDISPLAYを用意する事で解決 sudo apt install -y xvfb export DISPLAY=:1 nohup Xvfb -ac ${DISPLAY} -screen 0 1280x780x24 & 参考

以下のような感じでdockerを使用しようとするとエラー $ docker run -p 6080:80 --shm-size=512m seigott/tetris_docker:latest docker: Error response from daemon: Failed to inspect container 889f7a5e430eae61378641c551f37d6d212ab3058a8e1dbb05ce5ea40e207ba6: Error response from daemon: readlink /var/lib/docker/overlay2/l: invalid argument. image取得時に何かおかしな点があったような気がするので、imageを削除する。 $ docker images # imageを検索 $ docker rmi -f ${imageID} # imageIDを指定して、imageをremove もう一度実行すると問題は起こらなかった $ docker run -p 6080:80 --shm-size=512m seigott/tetris_docker:latest 参考 'failed to inspect container error' while trying to ssh into containers using ignite