はじめに 今までWindows版(v2.4.3)を使用してきたのですが、ゲームが15色に対応したからかAmongUsCaptureでも変更を吸収しきれず、AutoMuteUsがまともに動かなくなりました。 そこでdocker版を導入することにしましたので、どなたかの参考になればと思いアウトプットすることにしました。 (追記) Windows版（v2.4.3）をforkして15色対応版を作成している方がいましたので、今までWindows版でやってきた方はこれでよいかもしれません。 私はもう環境を作ってしまいましたので仕方ないですが……。 AutoMuteUsをダウンロード git cloneする方法を記載しますが、GitHubアカウントも無いしGitもないし、面倒だな…という場合はzipをダウンロードして展開してもOKです。 Assets内のSource code(zip)だけダウンロードして任意のフォルダに展開で終わり。 この方法を採用する場合、本項目をすっ飛ばしてよいです。 準備 GitHubアカウントの作成 Git for Windowsのダウンロード Git for Windowsは基本的にデフォルトでインストールでよかったと思いますが、人によってこだわりが出ると思いますので各自の判断におまかせします。 sshキーの生成 こちらを参考にしました。 私はGitをインストールした際に入れたGitBashでやりました。 ちなみに、Windowsでファイルからクリップボードにコピーするコマンドは以下です。 clip < ~/.ssh/id_rsa.pub 記事に従って、SSHキーをgitHubに登録します。 git cloneする 上記流れを行っていない場合、ここでSSHキーがなくて怒られます。 git clone https://github.com/denverquane/automuteus.git DiscordのBotを作成 以下記事内「v2.4.3の導入手順」の「1. Among Us の 公式 Steam版 を用意する」～「3. Discord の bot を作成する」を参考にしてください。 ただし、automuteus_windows はダウンロードしなくてよいです（今回はそれから脱却する記事なので）。 また、記事内に記載されていますが、botのトークンコードを控えておいてください。 設定ファイル（.env）を作成する 参考にしました。 ダウンロードしたautomuteusフォルダ（またはautomuteus-X.XX.Xフォルダ）内のsample.envを複製し、.envに名称を変更します。 編集する箇所は以下の項目です。 AUTOMUTEUS_TAG=X.X.X GALACTUS_TAG=X.X.X DISCORD_BOT_TOKEN=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX GALACTUS_HOST=http://XXX.XXX.XXX.XXX:8123 AUTOMUTEUS_TAG と GALACTUS_TAG は、それぞれの最新バージョンの番号を記載します。 https://github.com/denverquane/automuteus/releases https://github.com/automuteus/galactus/releases DISCORD_BOT_TOKENは「DiscordのBotを作成」で作成したBotのトークンコードを記載します。 GALACTUS_HOSTはPC1台で完結するのであればhttp://localhost:8123で動くと思います。 AutoMuteUsの環境を構築する 準備 docker for Windowsをインストールする とても参考にしました。 準備で問題が起きた場合 自分の環境では、インストール後の動作がスムーズに行きませんでした。その際の解決法について。 まさに、以下の記事のような状況になりました。 自分の場合は、PCを再起動してBIOS設定を変更することで解決しました。 BIOS設定は起動時にF10とかを連打して出てくる画面です。 docker-composeで環境構築、起動 コンソールでautomuteusフォルダ直下で以下コマンドを叩いて完了です。 docker-compose up -d dockerのGUIを見ると、Containers / Appsの一覧にautomuteusの文字があり、RUNNINGと記載されているはずです。 お疲れさまでした。 Among Usで遊ぶ dockerでAuteMuteUsが起動した状態でAmongUsCaptureを起動し、ボイスチャンネルに入り…… .au new で送られてきたメッセージからキャプチャのリンクを押せば動き出すはずです。 これで目的が達成できました。 AutoMuteUsの使用法などは詳しくないので是非調べてみてください。 最後に 様々な記事とにらめっこしたので、先人たちには頭があがりません。 本当にありがとうございます。 参考URL auto mute us 導入（難しい版） AutoMuteUs (Among Us の自動ミュート bot) のセルフホスティング - Qiita Windows 10 HomeへのDocker Desktop (ver 3.0.0) インストールが何事もなく簡単にできるようになっていた (2020.12時点) - Qiita [Among Us] automuteus v4.0.4をdocker-composeで起動 - Qiita Among Us 用超便利 Discord bot “AutoMuteUs” をセルフホストする方法 (公式推奨簡単版) - Aqua Ware つぶやきブログ お前らのSSH Keysの作り方は間違っている - Qiita Dockerを起動しようとしたら「Hardware assisted virtualization and data execution protection must be enabled in the BIOS.」というエラーが出る場合の対処

WindowsをDockerのホストとゲストとして利用しており、ゲスト内からnpm ciがエラーになる問題でハマりました。 エラーは以下のようなメッセージ。 getaddrinfo EAI_AGAIN registry.npmjs.org:443 どうやら名前解決で失敗しているもよう。 Dockerの設定を開き、Docker Engineメニューのconfigurationに以下を追加してDockerを再起動して解決しました。 GoogleのDNSサーバーを追加しているようです。 "dns": ["8.8.8.8"] 参考 https://github.com/StefanScherer/dockerfiles-windows/issues/270#issuecomment-382229052

今回やる事 DRF、Vue.js、dockerでの環境構築をする上で、各ファイルの意味だったりコマンドだったりをよく忘れるので、とりあえずDRFとVueが連携出来るまでを、ほぼ自分用に残しておきます。 例として、ユーザー一覧を取得するだけの処理を実装します。 環境 docker $ docker version Version: 20.10.6 docker_compose $ docker-compose -v docker-compose version 1.29.1, build c34c88b2 python $ python --version Python 3.8.10 構築編 DBは開発段階ではsqliteを使い、DRF用にコンテナ1つ、Vue用にコンテナ1つを用意します。 サーバーはそれぞれの開発サーバーを使用するとします。 まずは、以下の様なディレクトリ構成でファイルを作成します。 アプリ名は「k2」です。 k2/ ├ api │ ├ Dockerfile │ └ requirements.txt ├ web │ └ Dockerfile └docker-compose.yml ※一部省略。 docker-composeを定義 まずは、docker-composeでDRF用のコンテナとVue用のコンテナを定義します。 docker-compose.yml version: '3' services: api: # Dockerfileの場所 build: ./api # どのimageを使うか。Dockerfileでimageは作成する。 image: k2-drf-image # コンテナ名を指定出来る。 container_name: k2-api # 公開用のポート。ホスト側:コンテナ側を指定 # コンテナ側のみ指定も可能だが、その時ホスト側はランダムになる。 ports: - '8000:8000' # マウントするパス volumes: - ./api/:/usr/src/k2/api/ # dockerコンテナを落とさず起動し続けるようにする tty: true web: build: ./web image: k2-vue-image container_name: k2-web ports: - '8080:8080' volumes: - ./web/:/usr/src/k2/web/ tty: true 次に、apiとwebのDockerfileを定義します。 apiのDockerfile # イメージを選択 FROM python:3.9.5-alpine # バイナリレイヤ下での標準出力とエラー出力を抑制 ENV PYTHONUNBUFFERED 1 # 開始ディレクトリ位置 WORKDIR /usr/src/k2/api # 必要なものをインストール # 今回はalpineなのでapkを使用する。 RUN apk update RUN apk add --no-cache --vertual=wow-ini-module \ net-tools \ sudo \ bzip2 \ curl \ gcc \ git \ python3-dev \ vim \ bash # ADDかCOPYを使うなら.dockerignoreを書いておく。 ADD . . RUN pip install --upgrade pip RUN pip install -r requirements.txt とりあえず最小限をrequirements.txtに記述する。 requirements.txt Django==3.2.4 django-cors-headers==3.4.0 django-environ==0.4.5 django-filter==2.3.0 djangorestframework==3.12.4 djangorestframework-jwt==1.11.0 gunicorn==20.0.4 requests==2.24.0 webのDockerfile FROM node:10.17.0 WORKDIR /usr/src/k2/web/ RUN apt-get update RUN apt-get install -y --no-install-recommends \ net-tools \ sudo \ bzip2 \ curl \ gcc \ git \ vim RUN apt-get clean RUN npm install -g yarn \ && yarn global add @vue/cli \ イメージ構築、コンテナ作成～立ち上げ $ docker-compose up -d --build コンテナに接続し、環境を整える ターミナルを2つ立ち上げてそれぞれで接続し、それぞれの最低限の環境を整える。 DRF側 $ docker-compose exec api bash $ django-admin startproject api $ django-admin startapp k2 $ python manage.py makemigrations $ python manage.py migrate $ python manage.py createsuperuser 上記で作ったファイル群を以下のフォルダ構成に直します。 k2/ └ api ├ api/ ├ k2/ ├ db.sqlite3 ├ Dockerfile ├ manage.py └ requirements.txt とりあえずこの段階で、python manage.py runserver 0.0.0.0:8000で開発サーバーは立ち上がる。 Vue側 $ docker-compose exec web bash vueプロジェクトの作成 ①現在のディレクトリにフォルダ群を展開する。 $ vue create . ? Generate project in current directory? (Y/n) y ②マニュアルで導入するものを選択する。 ? Please pick a preset: Default ([Vue 2] babel, eslint) Default (Vue 3) ([Vue 3] babel, eslint) ❯ Manually select features ③導入するものにスペースで☑を入れる。 ? Check the features needed for your project: ◉ Choose Vue version ◉ Babel ◯ TypeScript ◯ Progressive Web App (PWA) Support ◉ Router ◉ Vuex ◉ CSS Pre-processors ◉ Linter / Formatter ◉ Unit Testing ❯◉ E2E Testing ・Babel 　JSのコードを新しい書き方から古い書き方へと変換するツール。 　ブラウザによって古いバージョンしか対応していないため、このようなツールが必要になる。 ・PWA 　ネイティブアプリのような使い勝手を実現したWEBアプリの事。 　インストール不要で、ホーム画面やアイコン追加やプッシュ通知などが可能。 　そのほかに読み込み速度や表示の高速化、オフラインで閲覧化などのメリットもある。 ・CSS Pre-processor 　Sass, Less, Stylusなどのプリプロセッサ独自の構文でCSSを作成するプログラム。 　純粋なCSSにはない、ミックスイン、セレクターの入れ子、セレクター継承などが可能。 ・Linter 　ESLint等のコードフォーマッターなどを使用するか選択する。 ・Unit Testing（単体テスト） 　Mocha+Chainや、Jestなどを使用するか選択する。 ・E2E Testing（End to Endテスト） 　システム全体を通してテストを行う事。 　それらのライブラリなどを使うか選択する。 ④vueのバージョンを選択する。 3.x系だとvuetify Alphaしか対応してないみたいなので、今回は普通の2.xを使います。 ? Choose a version of Vue.js that you want to start the project with ❯ 2.x 3.x ⑤routerのhistoryモードを使うか選択。 ? Use history mode for router? (Requires proper server setup for index fallback in producti on) (Y/n) y ・historyモード 　ページのリロード無しにURL遷移を実現するhistory.pushState APIを利用したルーターのモード。シングルページのクライアントアプリなので、適切なサーバーの設定をしないと、404エラーが起きる。そのため、どのアセットにもURLがマッチしなかった場合に、index.htmlを返す設定が必要。 ・hashモード（vue-routerのデフォルト） 　完全なURLをhashを使ってシミュレートし、URLが変更された時にページのリロードが起きない。 ⑥ どのCSS pre-processorを使うか選択。 ? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default) : (Use arrow keys) ❯ Sass/SCSS (with dart-sass) Sass/SCSS (with node-sass) Less Stylus ⑦ linterを選択する。 ? Pick a linter / formatter config: (Use arrow keys) ❯ ESLint with error prevention only ESLint + Airbnb config ESLint + Standard config ESLint + Prettier ⑧ lintの追加の機能を設定 ? Pick additional lint features: (Press <space> to select, <a> to toggle all, <i> to invert selection) ❯◉ Lint on save ◯ Lint and fix on commit ⑨ unitテストに何を使用するか。 ? Pick a unit testing solution: (Use arrow keys) ❯ Mocha + Chai Jest ・Mochaは、BDD/TDDをするための枠組みを提供、chaiはテストを実施するための便利なメソッドを提供してくれる。TDD（テスト駆動開発）/BDD（振る舞い駆動開発） ・JestはFacebookが開発したテストランナ。 ⑩ E2Eテストに何を使用するか。 ? Pick an E2E testing solution: ❯ Cypress (Chrome only) Nightwatch (WebDriver-based) WebdriverIO (WebDriver/DevTools based) ・Cypress 　E2Eテストフレームワーク ・Nightwatch 　Seleniumを基盤として作られており、Node.jsでブラウザを操作してE2Eテストを行うツール ・WebdriverIO 　ウェブブラウザによるテストを自動的に実行するライブラリ ⑪ Babel, ESLintなどをどのファイルで管理するか。 ? Where do you prefer placing config for Babel, ESLint, etc.? (Use arrow keys) ❯ In dedicated config files In package.json ⑫ プリセットをセーブするか ? Save this as a preset for future projects? (y/N) n ⑬ どちらのパッケージマネージャーを使うか。 ? Pick the package manager to use when installing dependencies: (Use arrow keys) ❯ Use Yarn Use NPM これでvueのプロジェクトが出来上がり、yarn serveで開発サーバーが立ち上がる。 あと、必要に応じて下記のライブラリ等も導入しておく。 下の連携テストでは、 ・vuetify ・sass ・axios ・boxicons ・vue-loading-template を使っている。 # update yarn install # vuetify yarn add vuetify (vue add vuetify) # sass yarn add --dev sass # vuesax npm install vuesax # material-icons（アイコン） npm install material-icons --save # axios npm install --save axios vue-axios # boxicons（アイコン） npm i boxicons # lodash npm i --save lodash # vue-persistedstate npm i vuex-persistedstate # vue-session npm i vue-session # vue-loading-template npm install vue-loading-template --save 連携テスト とりあえず、ユーザー一覧をDRFから受け取ってそれを表示させるところまでをやります。 DRF側 やる事 初期設定 ルーティング View記述 DRF: 初期設定 k2/api/api/settings.py # 追加 import logging logging.basicConfig( level=logging.DEBUG, format='''%(levelname)s %(asctime)s %(pathname)s:%(funcName)s 行数:%(lineno)s:%(lineno)s %(message)s''' # 編集 ALLOWED_HOSTS = ['*'] # 追加 INSTALLED_APPS = [ ... 'rest_framework', # Json Web Token関連のライブラリ 'rest_framework_jwt', 'django_filters', 'k2.apps.K2Config', ] # 追加 REST_FRAMEWORK = { # デフォルトのパーミッションクラス 'DEFAULT_PERMISSION_CLASSES': [ 'rest_framework.permissions.DjangoModelPermissionsOrAnonReadOnly', ], # デフォルトの認証クラス 'DEFAULT_AUTHENTICATION_CLASSES': [ 'rest_framework_jwt.authentication.JSONWebTokenAuthentication', 'rest_framework.authentication.SessionAuthentication', 'rest_framework.authentication.BasicAuthentication', ], # デフォルトのフィルターバックエンド 'DEFAULT_FILTER_BACKENDS': [ 'django_filters.rest_framework.DjangoFilterBackend', ], # デフォルトのスロットルクラス 'DEFAULT_THROTTLE_CLASSES': [ 'rest_framework.throttling.AnonRateThrottle', 'rest_framework.throttling.UserRateThrottle', ], # デフォルトのスロットルの制限 'DEFAULT_THROTTLE_RATES': { 'anon': '100/day', 'user': '5/sec', } } # 追加 if DEBUG: # CORS関連の設定追加。 INSTALLED_APPS += ['corsheaders'] MIDDLEWARE = ['corsheaders.middleware.CorsMiddleware'] + MIDDLEWARE CORS_ORIGIN_ALLOW_ALL = True DRF: ルーティング k2/api/k2/urls.py from django.urls import path, include from . import views, viewsets from rest_framework.routers import DefaultRouter router = DefaultRouter() router.register('users', viewsets.UserViewSet) app_name = 'k2' urlpatterns = [ path('', include(router.urls)), ] k2/api/api/urls.py from django.contrib import admin from django.urls import path, include urlpatterns = [ path('admin/', admin.site.urls), path('api/', include('k2.urls')), ] DRF: View記述 今回はDjangoデフォルトのUserモデルを使用します。 k2/api/k2/viewsets.py from django.contrib.auth.models import User from serializers import UserSerializer from rest_framework import ( viewsets ) import logging logger = logging.getLogger(__name__) class BaseModelViewSet(viewsets.ModelViewSet): pass class UserViewSet(BaseModelViewSet): queryset = User.objects.all() serializer_class = UserSerializer def list(self, request, *args, **kwargs): return super().list(request, *args, **kwargs) k2/api/k2/serializers.py from rest_framework import serializers from django.contrib.auth.models import User import logging import logging logger = logging.getLogger(__name__) class UserSerializer(serializers.ModelSerializer): class Meta: model = User fields = '__all__' これで、localhost:8000/api/users/にアクセスすると、python manage.py createsuperuserコマンドなどで作成したユーザー一覧が返る。 Vue側 やる事 初期設定 ルーティング 画面実装 ajax投げて表示 Vue: 初期設定 main.jsでライブラリ等を読み込む。 k2/web/src/main.js import Vue from 'vue' import App from './App.vue' import router from './router' import store from './store' import http from '@/plugins/http' import vuetify from './plugins/vuetify' import eventHub from '@/plugins/eventHub' import 'boxicons/css/boxicons.min.css' Vue.config.productionTip = false Vue.use(http) Vue.use(eventHub) new Vue({ router, store, vuetify, render: h => h(App) }).$mount('#app') k2/web/src/App.vue <template> <v-app> <router-view/> </v-app> </template> <script> export default { name: 'App', } </script> axiosのデフォルト設定をしておく。 k2/web/src/plugins/http.js import Vue from 'vue' import axios from 'axios' import router from '@/router' export default { install: function (Vue, options) { const http = axios.create({ baseURL: 'http://localhost:8000/', xsrfCookieName: 'csrftoken', xsrfHeaderName: 'X-CSRFTOKEN', timeout: 10000, }) Vue.prototype.$axios = http } } k2/web/src/plugins/vuetify.js import Vue from 'vue' import Vuetify from 'vuetify/lib' Vue.use(Vuetify) export default new Vuetify({ }) 孫コンポーネントとか遠い関係のコンポーネントのイベントを検知するためのもの。 k2/web/src/plugins/eventHub.js import Vue from 'vue' const eventHub = { install: function (Vue, options) { Vue.prototype.$eventHub = new Vue() } } export default eventHub eslintがうるさいので最低限だまらせておく。 k2/web/.eslintrc.js ... rules: { 'no-console': process.env.NODE_ENV === 'production' ? 'warn' : 'off', 'no-debugger': process.env.NODE_ENV === 'production' ? 'warn' : 'off', 'no-tabs': 'off', 'indent': 'off', 'comma-dangle': 'off', 'eol-last': 'off', 'no-unused-vars': 'off', 'no-mixed-spaces-and-tabs': 'off', 'no-unneeded-ternary': 'off', 'vue/no-unused-components': 'off', 'no-multi-spaces': 'off' }, ... Vue: ルーティング 全体のルート k2/web/src/router/index.js import Vue from 'vue' import VueRouter from 'vue-router' import pages from './pages' Vue.use(VueRouter) const routes = [...pages] const router = new VueRouter({ mode: 'history', routes }) export default router ページ関連のルート k2/web/src/router/pages.js import { Home } from '@/views/index' const routes = [ { path: '/', name: 'Home', component: Home }, ] export default routes Vue: 画面実装 index.jsにコンポーネントを纏める。 k2/web/src/views/index.js export { default as Home } from './Home' Home画面のコンポーネント。今回はコンポーネント分けないで直書きしちゃいます。 k2/web/src/views/Home.vue <template> <div id="home_wrap"> <v-card flat tile > <div v-if="loading"> <Loading/> </div> <div v-else> <v-card-title> users </v-card-title> <v-list three-line> <template v-for="(user, i) in users"> <v-list-item :key="i" > <v-list-item-avatar> <i class='bx bxs-user'></i> </v-list-item-avatar> <v-list-item-content> <v-list-item-title> {{ user.username }} </v-list-item-title> <v-list-item-subtitle> id: {{ user.id }} </v-list-item-subtitle> </v-list-item-content> </v-list-item> </template> </v-list> </div> </v-card> </div> </template> <script> import Loading from '../components/Loading' export default { name: 'Home', components: { Loading, }, data: () => ({ loading: true, users: [], }), mounted () { this.getUsers() }, methods: { getUsers () { this.loading = true this.$axios({ url: '/api/users/', method: 'GET', }) .then(res => { console.log(res) this.users = res.data this.loading = false }) .catch(e => { console.log(e) this.loading = false }) } } } </script> <style lang="scss" scoped> #home_wrap { width: 1200px; margin: 0 auto; } </style> ロード画面のコンポーネント k2/web/src/components/Loading.vue <template> <div class="loading_wrap"> <vue-loading type="cylon" color="#aaa" :size="{ width: '50px', height: '50px' }" ></vue-loading> </div> </template> <script> import { VueLoading } from 'vue-loading-template' export default { name: 'Loading', components: { VueLoading, }, } </script> <style lang="scss" scoped> .loading_wrap { width: 50px; height: 50px; margin: 50px auto; } </style> まとめ こんな感じの画面になりました。

概要 ローカル環境で、Laravelスケジュールを設定して、自動実行してみたくて調べたことをメモする。 ファイル構成 以下のようなファイル構成で構築してみる。 ※ ソースコード：Github-reflet/laravel5.6 ├ docker // ← docker関連のフォルダ │ ├ cron │ │ ├ cron.root │ │ ├ Dockerfile // ← cron実行する(PHP-CLI) │ │ └ php.ini │ │ │ └ php │ ├ Dockerfile // ← Apacheから実行される(PHP-FPM) │ └ php.ini │ ├ src // ← Laravel関連のフォルダ │ ├ app │ │ ├ Console │ │ │ ├ Commands │ │ │ │ └ EmailSendCommand.php // ← メールをテスト送信するコマンド │ │ │ └ Kernel.php // ← スケジュール設定 │ │ ... │ │ └ yarn.lock │ └ docker-compose.yml cronコンテナについて phpコンテナ内でcronを起動するのが簡単かと思ったが、意外とうまくいかない。 ※ 下記に記載されている症状が発生... まあCMD変えたら、そらそうなるよね... (＾＾；) 　 → PHPコンテナのDockerファイルでCMDを書くとnginxコンテナと接続できなくなった そこで、PHPコンテナをベースにCRONコンテナを別途作成しました。 ./docker/cron/Dockerfile # PHP-FPMではなく、PHP-CLIで構築する (内容はほぼ同じ...) FROM php:7.3-cli # ... # cronインストール RUN apt-get install -y cron # ... # cron設定 ARG CRON_FILE='/etc/cron.d/cron' COPY ./docker/cron/cron.root $CRON_FILE # cron実行ログを標準出力に出力するため、シンボリックリンクを用意する RUN chmod 0644 $CRON_FILE && \ ln -sf /proc/1/fd/1 /var/log/cron.log # ... # cronをフォアグラウンドで起動する CMD cron -f cron設定について crontabの設定は以下のようにしました。 ./docker/cron/cron.root * * * * * root /usr/local/bin/php /var/www/www.example.com/artisan schedule:run >> /var/log/cron.log 2>&1 ※ シンボリックリンク ( /var/log/cron.log )で、標準出力に接続する docker-composeの設定について 以下のようにcronとphpコンテナの２つを起動するようにしてみました。 ./docker-compose.yml version: '3' services: php: image: my-laravel5.6/php:7.3 build: context: ./ dockerfile: ./docker/php/Dockerfile tty: true ports: - '9000:9000' volumes: - ./src:/var/www/www.example.com:cached depends_on: - mysql cron: image: my-laravel5.6/cron:7.3 build: context: ./ dockerfile: ./docker/cron/Dockerfile tty: true volumes: - ./src:/var/www/www.example.com:cached depends_on: - php ... サーバ起動 dockerを起動してみる。 $ docker-compose build cron確認 テストメール送信する $ php artisan emai:test コマンドを1分ごとに実行している。 下記コマンドにて、定期状況をログで確認してみる。 $ docker-compose logs cron cron_1 | No scheduled commands are ready to run. cron_1 | No scheduled commands are ready to run. cron_1 | No scheduled commands are ready to run. cron_1 | No scheduled commands are ready to run. cron_1 | Running scheduled command: '/usr/local/bin/php' 'artisan' email:test > '/dev/null' 2>&1 cron_1 | Running scheduled command: '/usr/local/bin/php' 'artisan' email:test > '/dev/null' 2>&1 cron_1 | Running scheduled command: '/usr/local/bin/php' 'artisan' email:test > '/dev/null' 2>&1 cron_1 | Running scheduled command: '/usr/local/bin/php' 'artisan' email:test > '/dev/null' 2>&1 問題ないようですね。 参考資料 Laravel 5.6 タスクスケジュール Docker + Cron環境を実現する３つの方法 Laravelでschedule:runしたときのoutputがdockerで標準出力されない問題を解消 LaravelにDockerファイルでcronを導入して定期的にメール送信する方法 以上

Docker環境をUbuntuからWindowsへ移設(コピー)し起動する 背景 もともと、サブ機でUbuntuを稼働させており、そこでDockerやDocker-Composeを 利用できるような環境を構築していました。 今回、有志との活動の一環で、Windows上にDocker Desktopを構築したのですが、 その環境でも愛用していたaws-cliが利用できるコンテナを使いたくなり、 UbuntuからWindowsに移設(コピー)して両環境で利用できるようにしたいと考えました。 目的・やりたいこと ・ Windows10上のDocker Desktopでaws-cliが利用できるコンテナを稼働させる。 ・ 実際にAWSにアクセスしてaws-cliが利用できることを確認する。 環境 ・ Windows環境に、Docker DesktopとGit for Windows がインストールされていること。 ・ AWSにaws-cliでアクセスできること(アクセスキー、シークレットアクセスキーを入手済みであること) 関連記事 WindowsにDocker Desktopをインストールする 手順 まずはUbuntu環境からWindows環境へコンテナ起動に必要なファイルをコピーします。 コピー方法はいろいろあると思いますのでここでは割愛します。 最初に、Docker Desktopを起動します。 次に、コンテナ軌道に必要なファイルが格納されているフォルダにエクスプローラでアクセス。 フォルダ内で右クリックし、「Git Bash Here」をクリック。 以下のコマンドを実行し、コンテナを起動します。 $ docker-compose run --rm aws-cli bash ですが、Git for Windowsで実行すると、Ubuntu上で実行したときと動作が異なり、 プロンプトが帰ってきてくれませんでした。 $ docker-compose run --rm aws-cli bash Creating aws_aws-cli_run ... Creating aws_aws-cli_run ... done Docker Desktopを見ると起動はしているようです。 cliボタンがあるのでこちらをクリックしてみました。 すると、別ウィンドウでコンソールが表示されました。 ここからだと、普通にコマンドが打てるようでした。 ちょっとした操作の違いはあれど、何とか使えそうです。 aws-cliを利用するために、aws configureを実行し設定します。 # aws configure AWS Access Key ID [None]: xxxxxxxxxx AWS Secret Access Key [None]: xxxxxxxxxx Default region name [None]: xxxxxxxxxx Default output format [None]: json 試しにiamユーザ一覧でも取得してみます。 無事に実行でき、情報を取得できていることが確認できました。 # aws iam list-users --query 'Users[].UserName' 最後に aws-cliというコンテナ名ですが、このコンテナではansibleもkubectlも実行できるので 実はとても重宝しているコンテナだったりします。 (プロセス分離の考え方には反しているかもしれないとは思っていますが．．．) dockerの特性なので当たり前のことなのですが、環境が異なってもちゃんと起動でき、 しかも同じ環境を手に入れることができました。 知識としては理解していましたが、実際に異なる環境で起動させてことはなかったので 今回はとても良い検証となりました。

laravel　+ dockerでやっていたプロジェクト。 最近dockerをリフレッシュしてコンテナが消えたので環境構築をし直す機会がありました。 いつもどおりgitリポジトリから git clone リポジトリURL docker-compose build docker-compose up とコマンドを入れていく … データベースコンテナだけが起動に失敗している。 エラーログを見ると MYSQL_USER="root", MYSQL_USER and MYSQL_PASSWORD are for configuring a regular user and cannot be used for the root user zac_db | Remove MYSQL_USER="root" and use one of the following to control the root user password: というエラーが出ていた。 以前と同じやり方なのになんで？ 英語力低いのでちょっと何言ってるのかわからないですね状態なので、取り敢えずgoogle翻訳にかけてみる mysql_user = "root"、mysql_user、およびmysql_passwordは、通常のユーザーを構成するためのものであり、rootユーザーには使用できません。 mysql_user = "root"を削除し、次のいずれかを使用してrootユーザーのパスワードを制御します。 ??? はい？ 取り敢えずrootという名前がだめらしい？ 結論 rootを消してみた。 docker-compose.ymlのrootを docker-compose.yml # db db: image: mysql:5.7.33 container_name: database environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: laravel MYSQL_USER: root MYSQL_PASSWORD: root TZ: 'Asia/Tokyo' 以下に変更。rootをroot2に変更 docker-compose.yml # db db: image: mysql:5.7.33 container_name: database environment: MYSQL_ROOT_PASSWORD: root2 MYSQL_DATABASE: laravel MYSQL_USER: root2 MYSQL_PASSWORD: root2 TZ: 'Asia/Tokyo' … 通った。 database起動！ よくわからないが最近の仕様変更でrootを使用できなくなったらしい。root以外にすれば大丈夫そう。 なんでやねん （セキュリティー的な問題？） 調べたら同じような症状で躓いている人が多そう。MySQLのDockerイメージが更新されたことが原因らしい

はじめに 日常業務だと、どうしても同じ言語ばかり使うことになってしまいがち しかし、新しい言語を学んでおくことは将来への投資になります 多くの言語を扱えることのメリット 要求機能、並列性、耐障害性、メモリ効率、開発規模などに応じて、適切な言語を選択できる 色々な言語の特性やメリットを他言語の開発にも活かせる 様々なOSSなどのコードを読めるようになる 自分の担当領域以外のコードも理解でき、トラブルシューティングに強くなる フロントエンドの開発をしていて、APIの挙動で「あれ？」と思ったとき、ちらっとバックエンド側のコードを見てバグを指摘したりできるのは強いです（逆もまた然り） というわけで、色々な言語の開発環境をざっくり作るためのリポジトリーを作りました ついでに分岐やループの例も書いておきました 時間のあるときにコンテンツを充実させていこうと思います 現時点で実装した言語は以下の通り Dart elixir elm Go Java Kotlin Markdown Node.js PHP Python R Ruby Rust Scala Shell Script Swift Ubuntu 上での asdf swift が上手く動作しないため Docker のみ おまけで Docker や asdf では環境構築できないけど、 Windows 系の Hello, World も PowerShell VBA VBS Windows batch 環境構築方法 Docker 素早い環境構築といえばこのお方ですね 各言語は Docker Hub にイメージを上げているので、それらを使えば一瞬で環境構築できます FROM elixir:1.11.4 WORKDIR /work docker-compose.yaml でローカルディレクトリーのマウントを指定すれば、毎回自分のエディターで書いたものをコンテナ内で実行できます version: "3" services: elixir: build: . container_name: elixir tty: true volumes: - "./scripts:/work" docker-compose up -d で起動させたコンテナに docker exec -it elixir /bin/bash で入れば、もう実行可能です docker-compose up -d docker exec -it elixir /bin/bash コンテナの中で各言語の仕様に従って実行すれば、すぐに Hello, World! が実行できます $ elixir hello.exs Hello, world! ひととおり動かし終わったらコンテナを止めてください コンテナから出る exit コンテナを停止・削除する docker-compose down asdf もう一つの手法として、 asdf でのインストール方法も載せておきました こちらはラインタイムバージョン管理ツールで、ローカル環境に簡単に多種言語の多数バージョンをインストールできる 使い方は簡単 まず使いたい言語のプラグインを追加する asdf plugin add erlang asdf plugin add elixir そして、インストールを実行する asdf install erlang 24.0.2 asdf install elixir 1.12.1 このとき、当該ディレクトリーやその親に .tool-versions ファイルがあれば、そこで指定されている言語・バージョンが全てインストールされる asdf install これでローカル環境でそのまま各言語が使えるようになる $ cd scripts $ elixir hello.exs Hello, world! ただし、ローカル環境に言語をインストールするため、インストールの前提となっているパッケージなどは事前にインストールしておく必要がある 例えば、 Ubuntu 20.04 で Elixir の 1.12.1 を使う場合は言語のインストール前に以下を実行する必要がある apt install -y \ automake \ autoconf \ build-essential \ default-jdk \ fop \ libgl1-mesa-dev \ libncurses5-dev \ libsdl2-dev \ libsdl2-2.0-0 \ libssl-dev \ libxml2-utils \ unzip \ xsltproc 当然、 Ubuntu のバージョンが違ったり、 CentOS だったり、 macOS　だったりすればまた違ってくる 当然、自分のローカル環境に影響を与えるため、あまり色々入れていると不整合を起こす可能性もある 更に、 Windows だと asdf は使えないため、 WSL 上で実行しなければならない 注意点 プロキシー プロキシーサーバーがいる場合、 Dockerfile 等々をいじらないと動きません 各種パッケージツール等についても同様です ストレージ Dokcer も asdf も無闇矢鱈とコンテナを立てたり、いろんな言語やバージョンをインストールしていると、ストレージをものすごく消費します いらなくなったら削除しましょう Docker使っていないものの一括削除 docker container prune docker image prune asdf で不要になった言語、バージョンの削除 asdf uninstall elixir 1.12.1 まとめ Docker と asdf のそれぞれで各言語・各バージョンの実行環境を構築した 低リスクですぐに使いたい場合はやはり Docker がおすすめ ただし、 macOS の Docker がローカルのディレクトリーをマウントしていると遅くなる問題などあるので、じっくり使いたい場合は asdf を使うのがおすすめ

sudo docker-compose run web rails new . --force --no-deps --database=postgresql --skip-bundle コンテナを作成しようとしたところ、以下のエラーが発生しました。 ERROR: Couldn't connect to Docker daemon at http+docker://localhost - is it running? If it's at a non-standard location, specify the URL with the DOCKER_HOST environment variable. 原因 結論から申し上げますと、今回の場合はdockerのサービスを開始していなかったのが原因でした。 解決策 sudo systemctl start docker を行ない、docker サービスを起動させ、再度 sudo docker-compose run web rails new . --force --no-deps --database=postgresql --skip-bundle を実行したら解決しました。 補足 権限によっても同様のエラーが出る場合もあるようです。 その場合はDockerとdocker-composeにそれぞれ権限を付与する必要があります。 sudo usermod -aG docker $USER sudo chmod +x /usr/local/bin/docker-compose 実行後、設定を反映させるために一度ログアウトする必要があるようです。 Exit 参考 参考にさせていただきました。ありがとうございます。

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. See 'docker run --help'. dockerをインストール後に、サービスを起動しようとしたら出てきた 環境 windows 10 pro [Version 10.0.19041.985] 実施したこと インストーラーをDL https://docs.microsoft.com/ja-jp/windows/wsl/install-win10#step-4---download-the-linux-kernel-update-package ここからDL インストーラー実行 適当に”はい”を選択してインスコ WSLのデフォルト設定 powershellから下記コマンドを実行 念のため管理者権限で起動した wsl --set-default-version 2 PC再起動をしたらエラーは表示されなくなった

はじめに なぜDockerについて勉強しようと思ったかというと、システムエンジニアのインターンに行った際に「Docker使ったことある？便利だよ。」と言われ、Dockerについて色々調べて、記事を読んでいたら、社会的には広く使われている便利なツールで使ったことがない人は危機感を持った方がいいということが判明したことと、授業でも仮想化技術のところでDockerが出てきたので勉強してみようと思った。 仮想化技術について　参考1　　参考2 仮想化技術はいくつかの種類に分けられる。 仮想環境のメリット コスト削減 これまで複数のハードウェアが必要だったものが一つに集約でき、機器を購入するコスト削減、電力などのランニングコストの削減、サーバを管理するための人件費やハードウェア保守費用の低下が見込める。 業務効率化 ハード機器の数が減るため、メンテナンスなどん管理にかかる手間が減る。また、アプリケーションのバージョンアップに合わせてのOS更改が必要になってもハードの数が少ないのですぐにできる。 拡張性 １つのサーバのメモリを拡張したいとなった時は、メモリやディスクを追加するために、機械を分解する必要があるため、稼働を停止して作業をする必要があるが、仮想環境上であればメモリを割り当てることで物理的な工事の必要が少なくなる。スペックを拡張するためには一度、仮想環境を停止し、パラメータを設定する必要があるが、物理サーバを拡張するよりも運用停止時間を短くできる。 耐障害性 仮想環境は１つのファイルとしてバックアップを取得できるので、物理サーバが故障してもバックアップファイルを別のハードウェアに移行すれば運用の継続が可能。 仮想環境のデメリット 性能が劣る 仮想環境は仮想かソフトウェアによって作られるため物理的な環境と比べて仮想化の処理があるので、割り振ったリソースよりも性能が劣る場合がある。物理的なメモリやディスク、CPUっを分割して各仮想環境に割り振るため、十分なリソースを確保できず、パフォーマンスが発揮できない場合がある。 運用管理 物理的なサーバに比べると、仮想化の概念や知識が必要となるため、仮想技術を習得した人材の確保が必要となる。運用方法も少し複雑になるので、計画を綿密に考えなければならない場合がある。 セキュリティ管理 セキュリティ管理も通常のサーバと比べると特別な対策が求められる。OSやアプリケーションによるセキュリティ対策と、仮想環境特有のセキュリティ管理が必要となる。仮想環境は、あらゆるサーバが相乗りするため、どのような手段でどこを守るかを考える必要があり、ウイルスに感染したときの感染経路の遮断や、各仮想環境に対するセキュリティ対策など、計画的に考慮する必要がある。 仮想環境の種類 ホスト型 ・パソコンやサーバにホストOSをインストールし、そのOS上に仮想環境作成ソフトウェアをインストールして構築するタイプ。ホストOSの上にゲストOSが並ぶ。 メリット ・仮想化に必要なソフトウェアが使いやすい。 ・既存マシンが使える。 ・テスト環境などを作成したいときに便利 デメリット ・ホストOSを動作させる物理リソースが必要 ・ゲストOSを運用する場合にホストOSでの処理速度が限定的になる。 ・既存のサーバなどにインストールすればすぐに始められるメリットがあるが、ホストOSを起動しなければならないので、ハードウェアを起動する際にホストOSが立ち上がるまでの時間がかかる場合がある。 ex)VMwareWorkstation Player,WMware Fusion,Oracle VM Virtualbox ハイパーバイザー型 ・一つのハードウェアに仮想化ソフトウェアを直接インストールし、仮想化を構築するタイプ メリット ・ホストOSが不要でハードウェアを直接制御が可能 ・システム全体の観点からみてリソースの使用効率がよい ・管理するサーバの台数削減が可能 ・ホストOSを起動しなくて良いので比較的早い起動が可能。 ・ホストOSがないので、リソースのほとんどを仮想環境に使える。 デメリット ・新しいハードウェアを購入する必要があるので、コストがかかる。 ・仮想化環境の高度な管理を実現するツールが標準装備されていない場合がある。 ・ハードウェアのスペックが低かった場合は処理能力不足になる可能性がある。 ・頻繁にアップデートを要するものがあるため専門的な知識や技術が必要。 ex)Microsoft Hyper-V,Citrix Xen Server,Red Hat Enterprise Virtualization コンテナ型 ・仮想環境の種類の中でも新しいタイプで、ホストOSにコンテナエンジにと呼ばれる仮想化ソフトウェアをインストールし、その中でコンテナと呼ばれる環境を作り、アプリケーションを実行させる。 メリット ・コンテナ型にはゲストOSという概念がない。ホストOSからは、一つのプロセスとして認識される。 ・余分なリソースが不要で、快適な環境を提供でき、アプリケーションを短期動で起動可能。リソース効率がよくコストパフォーマンスに優れている。 ・不可が小さく高速な動作が実現可能。 ・比較的容易でコピーも簡単なため作業時間の大幅な短縮が可能。 ・開発と運用の相性が良くリリースサイクルの高速化が期待できる デメリット ・新しい技術ということもあり、構築できるベンダーが少ない、便利な管理ツールが不足している。 ・複数のホストでのコンテナ運用が煩雑になる。 ・カーネルを他のコンテナと共有するため個別に変更できない。 ・新しい技術であり学習コストが比較的高い。 ex)Docker,Kubernetes Dockerについて Dockerとは？ Dockerは仮想化技術の中でもコンテナ型に分類される。Docker社が開発したコンテナタイプの仮想環境のなかで、アプリケーションを作成したり、配布したり、実行したりすることができるプラットフォーム。 Dockerを使うメリットは？ 軽量で効率的な作業が可能 ・dockerは仮想マシンと比較して軽量なため高速でアプリケーションの作成、実行ができる。 ・コンテナのイメージが軽量なので、エンジニアと共有する際に時間をかけずにダウンロードが可能 コード化されたファイルで同じ環境が作れる ・Dockerではインストールや各種環境設定をコード化できるため、開発肯定で作成した環境をコード化し、同じ環境で本番環境を作ることができる。そのため、環境によるリスクを軽減できる。 配布しやすい ・Dockerでは、web上のDocker HubでDockerイメージを取得すれば、すぐに使用できるコンテナが起動できる。 ・Dockerイメージを他者に配布しやすく、環境バージョンのずれや、環境準備に伴うミス防止や作業時間の短縮につながる。 スクラップ＆ビルドが楽 ・Dockerイメージはコンテナ名を変えて新たな開発に使えるため、環境を作る必要がなくなる。 Dockerで何ができる？ ・DockerによってOS内に独立した仮想環境（コンテナ）を複数生成することができ、コンテナによってOS内に多面の実行環境を構築でき、多種多様の開発検証環境や開発環境の変更にも柔軟に対応が可能。 ・独立した環境コンテナを生成することでファイルやバージョン、設定やポートの競合回避ができ、開発環境の共通化を推進できる。 ・Infrastructure as a Codeと呼ばれるように、インフラをコード化しようという考え。オンプレミス型ではサーバの用意、OSノインストール、アプリケーションサーバ、DB等のミドルウェアのインストールというように作業が多くなり、時間がかかるもので、少しでも設定を間違えるとアプリケーションが正しく動作しないという問題が発生する。それを解決するために考えられたもの。 ・immutable infrastructureといってセットアップしたサーバに、後から変更を加えないようにすることで、安定的に運用ができる。 Dockerでの開発を助けてくれるもの 参考 Docker Hub ・GithubのようにDockerのイメージを共有できるサービス。自分の作成したDockerイメージをクラウド上にアップロードして共有すること、ダウンロードして利用することが可能。 Docker Compose ・複数のコンテナを同時に利用するようなアプリケーションにおいて、複数のコンテナの連携を実現させるツール。 Kubernetes ・複数のコンテナを利用する複雑なアプリケーションの管理を用意にする技術。 Dockerで使用される用語　参考 ・Docker Engine・・・コンテナ化及びコンテナを動作させるためのアプリケーションでDockerの核 ・コンテナ・・・Docker上で動作するアプリケーションの単位。 ・Docker Image・・・コンテナを作成するための依存関係や情報を含むデータ。 ・Dockerfile・・・Docker Imageをビルドするための手順が記載されたファイル。自身で作成することも可能。 実際にDockerを使える環境を構築する。 For Mac 参考 ダウンロード、インストール https://docs.docker.com/docker-for-mac/install/ から最新のDockerをダウンロードしインストールする。 docker --versionができるかどうかを確かめる。 $ docker --version Docker version 20.10.7, build f0df350 DockerイメージからDockerコンテナの新規作成 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES LaunchpadからインストールしたDockerを起動していないと"Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?"というエラーが出ました。 Dockerが起動しているかどうかは上のバーにクジラのマークがあるかどうかでわかります。 psコマンドで動いているDockerコンテナのリスト取得 $docker run hello-world runコマンドでDockerイメージをもとにDockerコンテナを新規作成 正常に動くと・・・ Hello from Docker! This message shows that your installation appears to be working correctly. To generate this message, Docker took the following steps: 1. The Docker client contacted the Docker daemon. 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. (amd64) 3. The Docker daemon created a new container from that image which runs the executable that produces the output you are currently reading. 4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal. To try something more ambitious, you can run an Ubuntu container with: $ docker run -it ubuntu bash Share images, automate workflows, and more with a free Docker ID: https://hub.docker.com/ For more examples and ideas, visit: https://docs.docker.com/get-started/ って感じでメッセージが出ます。 まだ書き途中で、都度追記していく。

はじめに なぜDockerについて勉強しようと思ったかというと、システムエンジニアのインターンに行った際に「Docker使ったことある？便利だよ。」と言われ、Dockerについて色々調べて、記事を読んでいたら、社会的には広く使われている便利なツールで使ったことがない人は危機感を持った方がいいということが判明したことと、授業でも仮想化技術のところでDockerが出てきたので勉強してみようと思った。 仮想化技術について　参考1　　参考2 仮想化技術はいくつかの種類に分けられる。 仮想環境のメリット コスト削減 これまで複数のハードウェアが必要だったものが一つに集約でき、機器を購入するコスト削減、電力などのランニングコストの削減、サーバを管理するための人件費やハードウェア保守費用の低下が見込める。 業務効率化 ハード機器の数が減るため、メンテナンスなどん管理にかかる手間が減る。また、アプリケーションのバージョンアップに合わせてのOS更改が必要になってもハードの数が少ないのですぐにできる。 拡張性 １つのサーバのメモリを拡張したいとなった時は、メモリやディスクを追加するために、機械を分解する必要があるため、稼働を停止して作業をする必要があるが、仮想環境上であればメモリを割り当てることで物理的な工事の必要が少なくなる。スペックを拡張するためには一度、仮想環境を停止し、パラメータを設定する必要があるが、物理サーバを拡張するよりも運用停止時間を短くできる。 耐障害性 仮想環境は１つのファイルとしてバックアップを取得できるので、物理サーバが故障してもバックアップファイルを別のハードウェアに移行すれば運用の継続が可能。 仮想環境のデメリット 性能が劣る 仮想環境は仮想かソフトウェアによって作られるため物理的な環境と比べて仮想化の処理があるので、割り振ったリソースよりも性能が劣る場合がある。物理的なメモリやディスク、CPUっを分割して各仮想環境に割り振るため、十分なリソースを確保できず、パフォーマンスが発揮できない場合がある。 運用管理 物理的なサーバに比べると、仮想化の概念や知識が必要となるため、仮想技術を習得した人材の確保が必要となる。運用方法も少し複雑になるので、計画を綿密に考えなければならない場合がある。 セキュリティ管理 セキュリティ管理も通常のサーバと比べると特別な対策が求められる。OSやアプリケーションによるセキュリティ対策と、仮想環境特有のセキュリティ管理が必要となる。仮想環境は、あらゆるサーバが相乗りするため、どのような手段でどこを守るかを考える必要があり、ウイルスに感染したときの感染経路の遮断や、各仮想環境に対するセキュリティ対策など、計画的に考慮する必要がある。 仮想環境の種類 ホスト型 ・パソコンやサーバにホストOSをインストールし、そのOS上に仮想環境作成ソフトウェアをインストールして構築するタイプ。ホストOSの上にゲストOSが並ぶ。 メリット ・仮想化に必要なソフトウェアが使いやすい。 ・既存マシンが使える。 ・テスト環境などを作成したいときに便利 デメリット ・ホストOSを動作させる物理リソースが必要 ・ゲストOSを運用する場合にホストOSでの処理速度が限定的になる。 ・既存のサーバなどにインストールすればすぐに始められるメリットがあるが、ホストOSを起動しなければならないので、ハードウェアを起動する際にホストOSが立ち上がるまでの時間がかかる場合がある。 ex)VMwareWorkstation Player,WMware Fusion,Oracle VM Virtualbox ハイパーバイザー型 ・一つのハードウェアに仮想化ソフトウェアを直接インストールし、仮想化を構築するタイプ メリット ・ホストOSが不要でハードウェアを直接制御が可能 ・システム全体の観点からみてリソースの使用効率がよい ・管理するサーバの台数削減が可能 ・ホストOSを起動しなくて良いので比較的早い起動が可能。 ・ホストOSがないので、リソースのほとんどを仮想環境に使える。 デメリット ・新しいハードウェアを購入する必要があるので、コストがかかる。 ・仮想化環境の高度な管理を実現するツールが標準装備されていない場合がある。 ・ハードウェアのスペックが低かった場合は処理能力不足になる可能性がある。 ・頻繁にアップデートを要するものがあるため専門的な知識や技術が必要。 ex)Microsoft Hyper-V,Citrix Xen Server,Red Hat Enterprise Virtualization コンテナ型 ・仮想環境の種類の中でも新しいタイプで、ホストOSにコンテナエンジにと呼ばれる仮想化ソフトウェアをインストールし、その中でコンテナと呼ばれる環境を作り、アプリケーションを実行させる。 メリット ・コンテナ型にはゲストOSという概念がない。ホストOSからは、一つのプロセスとして認識される。 ・余分なリソースが不要で、快適な環境を提供でき、アプリケーションを短期動で起動可能。リソース効率がよくコストパフォーマンスに優れている。 ・不可が小さく高速な動作が実現可能。 ・比較的容易でコピーも簡単なため作業時間の大幅な短縮が可能。 ・開発と運用の相性が良くリリースサイクルの高速化が期待できる デメリット ・新しい技術ということもあり、構築できるベンダーが少ない、便利な管理ツールが不足している。 ・複数のホストでのコンテナ運用が煩雑になる。 ・カーネルを他のコンテナと共有するため個別に変更できない。 ・新しい技術であり学習コストが比較的高い。 ex)Docker,Kubernetes Dockerについて Dockerとは？ Dockerは仮想化技術の中でもコンテナ型に分類される。Docker社が開発したコンテナタイプの仮想環境のなかで、アプリケーションを作成したり、配布したり、実行したりすることができるプラットフォーム。 Dockerを使うメリットは？ 軽量で効率的な作業が可能 ・dockerは仮想マシンと比較して軽量なため高速でアプリケーションの作成、実行ができる。 ・コンテナのイメージが軽量なので、エンジニアと共有する際に時間をかけずにダウンロードが可能 コード化されたファイルで同じ環境が作れる ・Dockerではインストールや各種環境設定をコード化できるため、開発肯定で作成した環境をコード化し、同じ環境で本番環境を作ることができる。そのため、環境によるリスクを軽減できる。 配布しやすい ・Dockerでは、web上のDocker HubでDockerイメージを取得すれば、すぐに使用できるコンテナが起動できる。 ・Dockerイメージを他者に配布しやすく、環境バージョンのずれや、環境準備に伴うミス防止や作業時間の短縮につながる。 スクラップ＆ビルドが楽 ・Dockerイメージはコンテナ名を変えて新たな開発に使えるため、環境を作る必要がなくなる。 Dockerで何ができる？ ・DockerによってOS内に独立した仮想環境（コンテナ）を複数生成することができ、コンテナによってOS内に多面の実行環境を構築でき、多種多様の開発検証環境や開発環境の変更にも柔軟に対応が可能。 ・独立した環境コンテナを生成することでファイルやバージョン、設定やポートの競合回避ができ、開発環境の共通化を推進できる。 Dockerでの開発を助けてくれるもの 参考 Docker Hub ・GithubのようにDockerのイメージを共有できるサービス。自分の作成したDockerイメージをクラウド上にアップロードして共有すること、ダウンロードして利用することが可能。 Docker Compose ・複数のコンテナを同時に利用するようなアプリケーションにおいて、複数のコンテナの連携を実現させるツール。 Kubernetes ・複数のコンテナを利用する複雑なアプリケーションの管理を用意にする技術。 Dockerで使用される用語　参考 ・Docker Engine・・・コンテナ化及びコンテナを動作させるためのアプリケーションでDockerの核 ・コンテナ・・・Docker上で動作するアプリケーションの単位。 ・Docker Image・・・コンテナを作成するための依存関係や情報を含むデータ。 ・Dockerfile・・・Docker Imageをビルドするための手順が記載されたファイル。自身で作成することも可能。 まだ書き途中で、都度追記していく。