「docker」を含む日記 RSS

はてなキーワード: dockerとは

2018-01-08

日本IT企業のココがイケてない

ってどこか連載してほしいと常々思うのだが。

大企業サイトが軒並みイケてない

言わずもがな楽天。なんだこれ。インターネットがこの世に出たころのようなデザイン、これはもはや意図的に使いにくさを追求しないと辿り着けないレベル

値段に神経質にこだわるユーザーくらいしかチェックしない。

銀行系、クレジットカード系、なんでもいいけど日常的に使わざるを得ないインフラを担うような会社サービス

大手企業だけどSIerに開発を丸投げしているような会社システム

もうすぐにエラーになるわ、URL名前おかしいわ、ちょっとたことに7クリックくらいしないと実現できない。リクルート系も同じくらいヤバイ

これは外注している会社全般にいえるけど、SIer技術レベルはやはりヤバイSIerはこの世から滅びたほうが社会のためになる。

退会の煩わしさとメール受信停止の面倒くささ

ユーザー視点で見事なまでに考えられていない。ここで苦労させることに何の意味があるのか。

日本辞書からおもてなしという言葉は取り除いてもらいたい。

道徳がまったくないサービスの乱立

Youtubeとか海外カンファレンスをみていると、よく「Make the world better place」ってフレーズをよく聞く。めちゃくちゃ聞く。

サービスによって世界をより良くしたいって思想の元にサービスを開発しているわけだ。

ところが日本はどうだ?

そんな発想がないどころか、「Make the Japan more chaotic place」って言葉がぴったりだ。

まりサービスによって日本もっと混沌とした場所にするってこと。日本経営者エンジニア社会的意義とか考えたことないやつばかりだ。

メルカリとか犯罪の温床になるようなサービスばかり提供し、ドヤ顔。昔流行ったソシャゲとか、そんなゴミを開発している会社だらけ、DeNAなんかソシャゲ以外の新規ビジネスでも問題だらけ、社会悪のもの。儲かればなんでもOKって会社ばかり。

社会全体に倫理がない日本とかホントどこに向かってるんだろ?

技術トレンドが2年くらい遅い

今時Dockerが〜とか恥ずかしげもなくそんな記事が今なお乱立する、まじかよ。

さらに開発環境に使いましたって糞みたいな記事が乱立する有様。Deployはどうした?

Qiitaとかゴミ記事プラットフォームと化しているかgoogle検索からまじで外してもらいたい。

さらRubyが〜Railsが〜なんて、世界でもPerl並に勢いよく廃れている技術を今なおスタートアップドヤ顔で使う。

まあそれはいいけど、あんパフォーマンス自由度高すぎて可読性も低い言語流行る時点でエンジニアリング思想普通に欠けてると思う。

技術手段ではなくて目的になりすぎ

さらマイクロサービスアーキテクチャーが〜っていって大した規模ではないスケール必要性がまったくないようなシステムにまで

無理に導入しているやつ。

もうエンジニアを辞めることを強くオススメする。

CTOって肩書があっても、こういうやつがい日本はもうほんとすごいわ。


なんか書いてて心が病んできたので、何かwebメディアで連載してもらいたい。

2018-01-06

docker win10のphpで、c:\users\unko\wwwマウントできない

前はできたんだけどなんとなくできなくなった

2018-01-01

[][][]Android Studioインストールして、ごちゃごちゃやってたらDockerがなんとなく起動しなくなったとき

Dockerの起動時に「biosVTオンにしてね」って言われる

biosの設定をみても、VTはオンになってる

 

コンパネ > プログラム > Windows機能有効化または無効化 > Hyper-V のチェックを外す

再起動

dockerを起動して、docker経由でHyper-Vを再設定する

(これは関係ないと思う。ふつうWindows操作からHyper-V 有効化でいいんじゃないかな?)

再起動

 

 

これで治った

クソだな

2017-11-29

ニコニコ動画(く)リリース失敗に寄せて

そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います

Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita

ドワンゴアカウントシステムScalaコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています

ドワンゴユーザーアカウント基盤は明らかに破綻しています10 年以上にわたりガラケー時代から今に至るまで多くの業務コードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います

ニコニコ生放送におけるdockerの活用事例:dwango エンジニア ブロマガ:ドワンゴ研究開発チャンネル(ドワンゴエンジニア) - ニコニコチャンネル:生活

ニコニコ生放送(以下「生放送」)ではバックエンドフロントエンドサーバーを建てる環境として、2016年からDocker Swarm採用し始めています

Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができますさらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上ゼロコンフィグレーション)で実装たことは素晴らしいと思いますしかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。

私は kubernetes が嫌いです。 Google 製品開発者UX考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます

http://gihyo.jp/dev/serial/01/dwango-engineersoul/0002 大量トラフィックを支えるインフラ独自プロトコル,ファイルシステム実装もいとわない!~

実は分散ファイルシステム独自に開発しました。もともと既存オープンソースファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自調査開発を進めることにしました。

現状は初期バージョンの開発完了にかなり近づいています

こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって

  1. OSS分散ファイルシステム使用するという目論見が失敗した
  2. 自前の分散ファイルシステムは 9 カ月まえの時点で全く完成していない

ということが分かります

なぜ彼らはパブリッククラウドCDN を使わないのか?

触れない話: 事実上全然稼働しなかった CTO北の将軍様

パブリッククラウド特に CDN採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザー結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定理由をここでは探ってみます

ASCII.jp:niconico(く)開発の遅れを謝罪

動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています

ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しか現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。

CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性

大規模配信 | 強烈な価格競争 原価割れ総合サービス提供で収支合わせ)

要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴCDN流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います

ただしこの点において今後もビジネス環境技術環境現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。

まとめ

まあもう無理でしょいろいろ

2017-11-26

anond:20171126183724

ローカルマークダウンで保存してるけど、なんか結局使いにくい

sublimeのタブで、↓で運用してる

エクセルめも

docker

sql

業務めも

日報

直近の作業

バッファコピペ受け渡し)

2017-10-31

日本IT業界がしょっぼいのは社会のせいであり、政治家のせいであ

政治家社会に対する影響はでかい

洗脳教育しようと思えば簡単にできるし、既成概念だって作り上げることができる。

日本人なんかステレオタイプ支配された人間だらけだ、超簡単

で、それは前置き。

日本IT業界は言うまでもなくしょぼい。

世界で急速に廃れてきているRubyに今なお熱狂する日本エンジニアDockerの開発環境の構築方法が〜と使い方も然ることながら他国ではデプロイにおける完全デファクトスタンダードとなっているのに2017年にそんな記事を出して大量のブクマゲット。

技術力と創造力がダブルでイケてないことはある意味すごい。

イノベーションがないとか誰か言ってたな。暇じゃないからとか馬鹿なことを言っていたな。

ビジネスイノベーションがないから競合だらけで時間カバーしようとしているんだぞ、逆だ。

しかイノベーションがないことを個人のせいにしていいのだろうか?

もしAirBNBみたいなサービス日本会社が一番最初に作ったとしたら?

おそらく外野からボロクソに叩かれて、問題レッテルを貼られて沈没

Uberだってそう、Fintechサービスだってそう。

世界で許容されているから初めて日本でも受け入れる土壌ができあがる。

日本コピー文化は後追い文化だ。

でも、日本初だったらそうはいかないと思う。だってこの社会前例がないことが嫌いだから

世界は常に合理性を求めている。

日本とまったく真逆。非合理性を良しとするこの土壌なんなの?

世界では革新的とされることは、ことごとく日本法規制にひっかかるのではないだろうか?

もし日本会社最初に始めたのならね。

からこれは社会のせいでもあり、そんな社会を作り上げてきた政治家のせいである。

2017-09-10

anond:20170910121642

ウソです

 

 

CentOSインストール
c:\>docker pull centos

c:\>docker run -i -t centos /bin/bash

# cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

pythonパスバージョン
# which pyhton
bash: which: command not found

# yum install which
Loaded plugins: fastestmirror, ovl

# which python
/usr/bin/python

# ls -l /usr/bin/py*
-rwxr-xr-x 1 root root   78 Nov  6  2016 /usr/bin/pydoc
lrwxrwxrwx 1 root root    7 Aug  1 17:23 /usr/bin/python -> python2
lrwxrwxrwx 1 root root    9 Aug  1 17:23 /usr/bin/python2 -> python2.7
-rwxr-xr-x 1 root root 7136 Nov  6  2016 /usr/bin/python2.7

# python --version
Python 2.7.5

yumとは
# which yum
/usr/bin/yum

# file /usr/bin/yum
bash: file: command not found

# yum install file

# file /usr/bin/yum
/usr/bin/yum: Python script, ASCII text executable

# head /usr/bin/yum
#!/usr/bin/python
import sys
try:
    import yum
except ImportError:
    print >> sys.stderr, """\
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

    %s

# yum --version
3.4.3
  Installed: rpm-4.11.3-21.el7.x86_64 at 2017-08-01 17:23
  Built    : CentOS BuildSystem <http://bugs.centos.org> at 2016-11-05 23:37
  Committed: Florian Festi <ffesti@redhat.com> at 2016-07-26

  Installed: yum-3.4.3-150.el7.centos.noarch at 2017-08-01 17:23
  Built    : CentOS BuildSystem <http://bugs.centos.org> at 2016-11-15 15:30
  Committed: CentOS Sources <bugs@centos.org> at 2016-11-03

  Installed: yum-plugin-fastestmirror-1.1.31-40.el7.noarch at 2017-08-01 17:23
  Built    : CentOS BuildSystem <http://bugs.centos.org> at 2016-11-06 00:11
  Committed: Valentina Mukhamedzhanova <vmukhame@redhat.com> at 2016-08-04

yum remove pythonしてみた
# yum remove python
Loaded plugins: fastestmirror, ovl
Resolving Dependencies
--> Running transaction check
---> Package python.x86_64 0:2.7.5-48.el7 will be erased
--> Processing Dependency: python >= 2.4 for package: yum-3.4.3-150.el7.centos.noarch
--> Processing Dependency: python >= 2.2 for package: pyxattr-0.5.1-5.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: yum-metadata-parser-1.1.4-10.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: python-kitchen-1.1.1-5.el7.noarch
--> Processing Dependency: python(abi) = 2.7 for package: pygpgme-0.3-9.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: python-pycurl-7.19.0-19.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: libxml2-python-2.9.1-6.el7_2.3.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: python-chardet-2.2.1-1.el7_1.noarch
--> Processing Dependency: python(abi) = 2.7 for package: dbus-python-1.1.1-9.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: python-urlgrabber-3.10-8.el7.noarch
--> Processing Dependency: python(abi) = 2.7 for package: pyxattr-0.5.1-5.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: yum-3.4.3-150.el7.centos.noarch
--> Processing Dependency: python(abi) = 2.7 for package: pyliblzma-0.5.3-11.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: pygobject3-base-3.14.0-3.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: python-iniparse-0.4-9.el7.noarch
--> Processing Dependency: python(abi) = 2.7 for package: yum-utils-1.1.31-40.el7.noarch
--> Processing Dependency: python(abi) = 2.7 for package: rpm-python-4.11.3-21.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: yum-metadata-parser-1.1.4-10.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: python-kitchen-1.1.1-5.el7.noarch
--> Processing Dependency: python(abi) = 2.7 for package: pygpgme-0.3-9.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: python-pycurl-7.19.0-19.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: libxml2-python-2.9.1-6.el7_2.3.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: python-chardet-2.2.1-1.el7_1.noarch
--> Processing Dependency: python(abi) = 2.7 for package: dbus-python-1.1.1-9.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: python-urlgrabber-3.10-8.el7.noarch
--> Processing Dependency: python(abi) = 2.7 for package: pyxattr-0.5.1-5.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: yum-3.4.3-150.el7.centos.noarch
--> Processing Dependency: python(abi) = 2.7 for package: pyliblzma-0.5.3-11.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: pygobject3-base-3.14.0-3.el7.x86_64
--> Processing Dependency: python(abi) = 2.7 for package: python-iniparse-0.4-9.el7.noarch
--> Processing Dependency: python(abi) = 2.7 for package: yum-utils-1.1.31-40.el7.noarch
--> Processing Dependency: python(abi) = 2.7 for package: rpm-python-4.11.3-21.el7.x86_64
--> Processing Dependency: python-sqlite for package: yum-3.4.3-150.el7.centos.noarch
--> Running transaction check
---> Package dbus-python.x86_64 0:1.1.1-9.el7 will be erased
---> Package libxml2-python.x86_64 0:2.9.1-6.el7_2.3 will be erased
---> Package pygobject3-base.x86_64 0:3.14.0-3.el7 will be erased
---> Package pygpgme.x86_64 0:0.3-9.el7 will be erased
---> Package pyliblzma.x86_64 0:0.5.3-11.el7 will be erased
---> Package python-chardet.noarch 0:2.2.1-1.el7_1 will be erased
---> Package python-iniparse.noarch 0:0.4-9.el7 will be erased
---> Package python-kitchen.noarch 0:1.1.1-5.el7 will be erased
---> Package python-pycurl.x86_64 0:7.19.0-19.el7 will be erased
---> Package python-urlgrabber.noarch 0:3.10-8.el7 will be erased
---> Package pyxattr.x86_64 0:0.5.1-5.el7 will be erased
---> Package rpm-python.x86_64 0:4.11.3-21.el7 will be erased
---> Package yum.noarch 0:3.4.3-150.el7.centos will be erased
--> Processing Dependency: yum >= 3.4.3 for package: yum-plugin-ovl-1.1.31-40.el7.noarch
--> Processing Dependency: yum >= 3.0 for package: yum-plugin-fastestmirror-1.1.31-40.el7.noarch
---> Package yum-metadata-parser.x86_64 0:1.1.4-10.el7 will be erased
---> Package yum-utils.noarch 0:1.1.31-40.el7 will be erased
--> Running transaction check
---> Package yum-plugin-fastestmirror.noarch 0:1.1.31-40.el7 will be erased
---> Package yum-plugin-ovl.noarch 0:1.1.31-40.el7 will be erased
--> Finished Dependency Resolution
Error: Trying to remove "yum", which is protected

 

 

結論

依存チェックではじかれて、pythonを削除できません

2017-08-16

Dockerって

root権限がないサーバーでもコマンドを入れられたりするものなの?

cmakeを最新バージョンで使いたいんだけど、root権限がないから使えなくて困ってる。

私用で使いたいから、管理者に問い合わせるわけにもいかない。

2017-08-02

知らない間にDebian9がリリースされてた

Dockerバズるくらいだから今どきハードウェア仮想化なんて流行らないのだろうが、Windows10 Proの安いPCを1つ購入してHyper-V有効化したのでCentOSUbuntuのどちらを入れようかと考えてた時に、昔インストールに苦労したDebian 3.1 Sargeのことを思い出して本家サイトに行ったら今年の6月Debian 9が正式リリースされたと聞いてすごく懐かしくなり、こいつを選択することにした。

随分バージョンが上がったものだなあ。しかも今はamd64インストーラーのリスト最初に上がってるし。昔は64は人柱用だったのに。

10年ほど前、玄人志向玄箱というNASOSDebianに入れ替えて単なるファイルサーバから用途サーバにするのが流行ったことがあった。今でも後継品のBuffaloNASDebian化する好事家は細々ながら活動しているが、UbuntuベースであるDebian最初に触れたのがその頃で、当時のバージョンは3.1、通称Sargeだった。タイミングのいいことに、Sarge対応の分厚いDebian入門書存在していたのでレファレンスには事欠かなかった。まあそれでも、スペックの貧弱な玄箱インストールして少しでもパフォーマンスをよくするにはカーネルを書き換えて再コンパイルしたりといった悪戦苦闘があったわけだがもう忘れた。

Hyper-V仮想マシンへのDebianインストールトラブルらしきトラブルもなく、インストールしてすぐに使えるようになっていてまあこれが普通だよなと。OSは使いこなしてなんぼで、インストールで苦労するのは不毛だと当時も思ったし。

あと、エンジニアが多いと聞いているはてな界隈でも個別ディストリトピックはあまり話題にならないんだなというのがちょっと面白かった。

2017-06-06

ウェブ開発者Mac じゃなくて Linux 使えばいいのに

ソフトウェア開発者といってもいろいろなのは承知しているが、サーバサイドのウェブRuby, PHP, Java, JavaScript, Python 等)をやっているエンジニアがどうして Mac にこだわる必要があるのかよく理解できない。

Linux デスクトップで十分じゃない?その方が安いし、自由度は高いし…。

どうせサーバはみんな Linux なんだし。Docker だってそのまま動くよ。

確かに Apple 製品品質高いんだろうけどさ…。

Apple のカモにされているとしか思えないんだよね…。

2017-05-24

いつでも探しているよ

Dockerに君の姿を

2017-05-06

Infrastracture as code (笑)

ansible

結局yamlデータ構造を現すもので、プログラミング的な繰り返しとかIF文は無理やり過ぎて違和感しかない

chef

RubyDSLって普通にダメねこりゃ。実行順序も分からんし、普通にRubyで書いた方が良い気さえする

puppet

独自のSyntax覚えるのかったるすぎる。大して便利じゃない

でどうなった?

何でもやろうとすると結局、プログラミング言語みたくなってどんどん可読性が落ちる

結局最後bashで良いんじゃねーかなってなる。シンプルにできるなら一番筋が良いのはansibleだけど微妙に書き方変わったりして追従がかったるい

俺の知ってる会社chefで全自動だぜ!とか言ってキラキラ感だしてる会社あったんだが今は全然回ってないらしいww

一時はもてはやされたけどDockerとか出てきた昨今こんなの今頑張らなくてもいいのかもな

2017-04-23

http://anond.hatelabo.jp/20170421160023

同じく海外ソフトウェア大手仕事してるけど、ここはDockerモドキのコンテナを内製してDockerよりいけてない車輪を再発明しちゃってるよ。こういうケースもあるから一概には言えない。

2017-04-22

DockerというよりDocker社が心配

あの会社ちゃんとマネタイズできてんのか?

DockerHubの運用だけでも相当な費用だろ

Docker界隈が荒れててうれしい

新しい方法論が出てきたとき

1.有名人がまず試して

2.新しいこと好きな人が次に試して

3.Qiitaブログにまとめる人が出てきて

4.上手く行ったよ、すごくいいよ、って人が出てくる

 

ここで流行となるんだけど、ここで勉強し始めてはいけない

 

5.次に、批判者が現れ

6.それでもこういう点では優れている、って言う人が現れる

 

6まで行った瞬間に、必要なら勉強をし始める

ここがベスト

この時点で遅くない、なぜならここまでにやり方がコロコロ変わるから

6まで行かなかったならやるな

趣味しかならん

 

6まで到達するのに2~3年かかるイメージが有る

 

Dockerはそろそろ5

dockerやめてどうしたか

この話の続き

systemd-nspawnに移行した

以下詳細とか雑記

ファイル差分管理がそもそも不要

docker commitもdocker diffも使わないし、要らない

要らないだけならまだしも、aufs、overlayfs周りでトラブル可能性がありむしろ邪魔

イメージ差分管理ファイルシステムの層でやるのが素直でコンテナ管理にくっついてるのに違和感がある

Dockerじゃないと今までのエコシステムが云々言ってるやつ

こういう事言うやつは本質をまるで理解してないやつ

Docker特有機能をフルに使ってる奴ならまだしもコンテナ動かすだけなら何使っても変わらねーよw

Docker Hub からイメージダウンロードしてtar解凍すりゃ良いだけじゃねーか

composeだって容易にコンバート可能だし、composeで何が起きるかわからない状態で本番運用とか口にしないで欲しい

実際systemd-nspawnの今でもベースDocker Hubから拾ってきてるし、Docker使ってる奴との受け渡しも問題ない

所詮ファイルを一つにまとめたものから

やりかたは runc.io のGetting startedでも見れば?

Dockerfile いけてない

あんなんメンテしたくねーよ

Docker hubでよくわかんねーイメージ落とすときに、出所クリアになるってメリットだけだなこんなん

文法覚えるのもメンテするのも労力に見合わない

取り急ぎansibleでセットアップは済ませてる

initの管理とか考えたくねー

コンテナにしたかプロセス管理は違う方法でやりますsupervisorで云々→めんどくさいだろ!

じゃあ1プロセス1コンテナにしてマイクロサービスします→本当に便利それ?管理できる?

ログ管理は?logrotateは誰がやる?データボリュームはどこにする?みたいなアホみたいな検討し始めたときに俺は会議室を出た

「いや今はこれが主流で流行ってるから便利です」みたいな事言ってるバカが居て殴りたくなった

社内への説得

「毎週、毎週swarmが壊れたバージョンアップ再起動だのと余計な仕事増やしやがって、いつまでDocker社のβテストに付き合うつもりだクズども」

とは言えないので

「今の状況は前よりも運用負荷が高い状況みたいなので、systemd-nspawn等のシンプルもの代替できないか検討してほしい」

と言ってなんとか説得

(結局半分以上は俺が対応したが)社内のクリティカルな部分のDockerは全部廃棄した

systemd-nspawnにしたら全部が普通になる

普通に起動して、普通に終了できる。コンテナの中なのにそれを意識しないくら普通に起動する。

aufs,overlayfs等の差分管理しなければそれに付きまとう問題もない(overlayfsとか使うこともできる)

自動起動も設定もコマンドコンテナ内だから〇〇しなきゃダメみたいなやつが無くなって、ものすごく安定してる

Dockerも--privilegedつけてinitからrunすればいいって?糞不安定だし、権限多すぎだろ?capabilitiesを適切に設定しろだって

一生やってろバーカ

まとめ

結局のところ本当にこれ便利になったんだっけ?って聞かれて理由を言える奴じゃないと何をやってもダメってことが分かった

これはDockerに限らず全部そうだと思う

QiitaとかにあるDockerでこんな素晴らしくなったよって記事の大半は本質を見失った馬鹿記事

楽になるどころか厄介事を+1してるだけ

とりあえずこっちはDockerのゴタゴタに振り回されなくなって良かったよって話

2017-04-21

http://anond.hatelabo.jp/20170309040708

日本エンジニアクズだが、書き手も目くそ鼻くそほどにバカだ。

海外エンジニアをしているが、Dockerを使ってない会社はこの数年、見たことがない。

開発環境だけで使っている会社もみたことがない。それじゃDockerメリットが何もない。

日本大丈夫か?

シェルや手順書のメンテナンスと変わらないだと?変わらない程度の環境構築しかできないやつがわかったようなことをいうな。

Dockerドキュメントを読み直せ。お前含め日本エンジニアはくずだ。

Mobyプロジェクトって何?

DockerConというカンファレンスのせいかMastodonのせいか、ここ数日はてなで頻繁にDocker文字を目にする気がする。

ところでDockerConで発表されて話題になっているというMobyプロジェクトって何?

https://github.com/moby/

追記

はてブを集めてるページがあるな

http://b.hatena.ne.jp/entry/dev.classmethod.jp/tool/docker/docker-moved-github-repository/

この説明でみんな理解できるのかな?

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん