仮想環境コンテナ総合スレ Docker、Vagrant等
よろしこ
Core i3とかメモリ4GBとかオンボードじゃきついですか？
スレ立て直し
どらいぶ帳よろしく
ポートフォワーディングで同一LAN内の別端末からhttpアクセスしたいのですが、うまくいきません。
config.vm.network "forwarded_port", guest: 80, host: 8080, host_ip: "127.0.0.1", id: 'http'
これだとvm立ち上げたPCからはlocalhost:8080でアクセスできますが、別端末からアクセスできません。
host_ipを192.168.3.8のように指定すると、別端末から192.168.3.8:8080でアクセスできますが、他のメンバーとvagrantfileを共有する際に編集する必要があります。
host_ipを指定しないと、The requested address is not valid in its context.のエラーが出ます。
どうにかうまく他のメンバーがvagrantfileを編集する必要なく、同一LAN内の別端末からアクセスできるようになりますか？
自分自身を指す特別なIPアドレスである。
「localhost」という名前でも参照できる
自分自身の上で動作しているサービスへ接続する場合は、
このIPアドレスを利用できる
Dockerfileだとテスト以後のマシンに使えないから困る
結局、同じ構成になるようにAnsibleでplaybookを書く二重管理状態になってしまう
device or resource busyです。
/var/lib/dockerも削除できません。
どうしたらDockerをリセットできますか？
気になるのは、devicemapper/mntにやたらとコンテナ？があります。
文字の羅列と同じ名称で語尾に-initがついてるもの。
これらすべでumountできません。
い
vargrant イメージ管理
docker アプリケーション絡みの構成管理
ansible ネットワーク絡みの操作とか色々
dockerってあくまで開発用途？
アプリケーションをデプロイするときに、
docker環境にpushして、そのdockerコンテナを
本番環境にpushするとか冗長化してるの？
Docker
アプリのカプセル化
Vagrant
仮想環境の新規作成
構成管理の起動
Ansible
すでにある環境の構成管理
インフラスキルってどのへんまで必要なの
Linuxの基本的なディレクトリ体系知ってたり、コマンド使いこなせればOK?
デバイスとかブートレベル、ネットワークのいじり方も必要？
個別のミドルウェアの設定ファイルやいじり方も熟知していないと駄目？
最低でも、LPICレベル1 は必要
じゃあそれできればそこそこ金になる？
金っていうのは会社が儲かっているかどうかできまる
いやいや金は大いに関係ある
会社が儲かっていようが無かろうが給料の配分は平等じゃない
会社が必要とするならば給料は高くなる、
上がらないならやめる。習得した技術の内容に需要があるならば
再就職先はあるはずだし、習得した技術の需要が高ければ待遇が
良くなる。だから金は関係ある。
インフラの習得は簡単ではない。しかしビジネスとインフラは直結
しないから、それを評価されうるか、金として還元されるかって超重要じゃね？
めっちゃ頑張って勉強してLPICとかとって、「動いて当たり前。資格なんて意味がない」
とかいわれたら洒落にならないよ。
だから、プログラマーよりも給料が高い
まず、コマンド・シェルスクリプトを知っている者が、少ない
皆、tmux も知らないだろ。
cron もまともに出来ない。環境変数が異なるから
( ) 内は、サブシェル・子プロセスで実行されるから、
親プロセスと環境変数は共有していないとか
OS・システムの内容は、プログラムよりも、めちゃめちゃ難しいから
OK ありがと。超やる気でたわ
技術力でもらえる金が決まるんじゃないよｗ
極端な例を言えばバスの運転手が
docker使えたって給料は増えない
需要がなければ、何ができたって価値はない。
需要は会社で決まる。
> プログラマーで、環境構築・運用ができる人は、まずいない。
そういうレベルの会社なのに給料が良いとでも？ｗ
そうですね。
結局給料は会社が儲かってるかどうかで決まりますからね
技術力が低くてdockerなど使わないような所でも
会社が儲かっていれば、給料は高くなりますよ。
その人がうまく自分をアピールできればね
「もうやらないよ？」っていう選択肢があるよ。
俺がいた前の会社には「CSSが書くのがめっちゃ速い」といって評価されている
人がいた。確かにCSSは自己アピールに最適だよ。
見た目ですぐにその人のデザインで主張できるから。ビジネス上の収益に関与できる。
WordPressもそんな感じだ。
JavaScript、サーバ側アプリケーション構築、インフラとなるにつれ
やる内容はマゾくなるわりに、外見上で評価されづらくなるよ。
だからといって「会社が儲かっているかどうかが全て」「ビジネスで成果出せ」
何ていう基準で給料がきまったら技術者なんてたまったもんじゃない。
世の中なんだってｗ
それが嫌なら、会社選ぶしかないよ
マ板にいけ
使われてないところでは、そもそも使わないから評価対象にならない
便利だとは思うけどうちはやる気のない会社だからこういう技術を正式に採用することはないだろう
起動したのは良いけれどvagrant sshで入った後
rootでもuser(vagrant guid)でも読めるが書けないdirがある
結果(sudo) setup.py install 出来ない
こまつた
そのディレクトリ chmodするとどうなるの?
基本的に1プロセスを上げるもの = Docker(Apacheだけとか、MySQLだけとか、そういうこと）
多連装仮想マシンランチャー = vagrants
まっさらのインスタンス(仮想マシンか物理かは知らん）に定型的な設定ファイル入れたり、aptなりyumのパッケージをぶっこむ = ansible(あるいはchef)
いちおうDockerで複数プロセス上げさせることもできるっちゃできるが面倒ではある
chmod 777 書けないdir
でやってみてどうなるかによる
で、chmodがエラーでハネられたらSELinuxRあたりか？ fedoraのatomic試したことないから知らんが
IPとかドメイン、パケットフィルタ関係のマシン外部の
設定までやりたい場合はDockerでいいの?
そういうのはansible
ansibleでやることは
ネットワーク/セキュリティなどホスト設定
Dockerインストール
コンテナ起動
この理論は美しすぎる。
まあ実際には冪等性にはならんけどなｗ
AnsibleだけにかぎらずChefなんかもそうだが、
「○○にする」という形で設定をすることができるが、
ここに書いたこと以外は無頓着
mysqlをインストールするという設定はできるが
PostgreSQLが入っていようが入っていまいが無頓着
PostgreSQLを消すと書かないかぎり、もしPostgreSQLが
入っていたとしてもなにもしない。
だから実行して作られた環境が必ず同じになるとは限らない
単に再度（二回以上）実行しても一回目と状態は変わらないというだけ
んで、最近はImmutable Infrastructureってことで
壊して最初からから設定して、その後変更しないので冪等性は必要なくなっている。
何度実行しても同じ状態になるではなくて一回しか実行しない。
あれ、冪等性とImmutable Infrastructureって違う意味なんだね、
同じことを言ってるんだと思った。いやいや、勉強になりました。
そうか、それでそのImmutable指向なのがDockerやvagrantなんだね。
Ansibleは、「マシン壊さないでスクリプト再実行」
Dockerは、「マシン構築してイメージを固めて、使いたいときはそれを複製
して構築状態を再現する」って感じ？
そう。書こうと思ってたけど他のスレに書き込んでいて遅れたけど、
Dockerでも完全な冪等性はない。
通常はイメージを作り直すたびに最新版として
更新が適用された形でイメージが作られる。
同じ手順でイメージを作るが、全く同じイメージができるわけじゃない。
もちろんそれは意図した動きであるので、問題あるわけじゃない。
そして全く同じものが欲しい場合は、作ったDockerイメージを使用する。
> Ansibleは、「マシン壊さないでスクリプト再実行」
そういうこと。もちろん壊してスクリプトを再実行しても良いが
アピールしている冪等性が有効に働くのは壊さないで再実行するときだけ
気軽に捨てていい端末だらけならこんなものは要らない
既存のマシンは簡単には壊せない
それが客の物ならなおさら
正直それ意味わからん。
客のものだろうがバックアップ取ったら片方は好きにいじればいいだろ。
コピー元が客のものだったとしても、複製したものは自分のものだろ。
個人情報云々も関係ないよ、マシン預けるってことは預けたマシンの中身を
全部知られてもいいってことだから。
そりゃ自社に複製した後なら作るのも捨てるのも自由だろうけど世の中そんな簡単じゃないよ
レガシとの絡みのせいで複製できない(複製するのに多大な工数がかかる)システムは少なくない
技術的には可能でも客のポリシの都合でできないこともある
客か別の企業がインフラの面倒を見てくれるならいいけど
権限を幾らか譲渡するのでうちに来て環境構築してくださいという案件も結構ある
こういう案件では同じ端末にすでに別のアプリが稼働している事が多い
そうなるとリスクが高すぎるからゼロから組み上げましょうなんて提案はできない
いやそれでもおかしい、
結局のところ仕事として請け負っている以上何かを変えなければ
何も達成しないわけで、部分的にディレクトリ構造だけでも切り出して
複製するなりして結局何か変えたり追加したりしなければ仕事に
ならないんだよ。
できない、費用対効果がなさすぎる、リスクが高すぎる或いは見積もり不可ならば
請け負うべきじゃない。
あなたに請け負う決定権がないなら決定した人間の責任。
それで失敗してとやかく言われたりするならば会社を辞めればいい。
上の方でも議論されてたけど。
企業体やビジネスだってImmutabuleでいいじゃんって思うんだよね今の時代。
無責任なこと言ってるみたいだけど最終的にそっちの方が正解なんじゃないかなぁ。
・「コンテナ」「イメージ」「スナップショット」という概念が導入された。
・DockerのためのコマンドAPIが充実しいている。
くらいなものか？
・AWSと比較したら、AWSよりも使い捨て性がよく、「スクリプト」を作る
仕組みが整っている。ってな感じかねぇ。
30だけど返事遅れてごめん
chmod 777 dir はread-onlyとか言われて
rwxr-xr-xだっけ？も変わらない
親dirも同じ
ググるとmountナントカをVagrantfileに書けってあって
やってみたけどループとか入れてるので
そのままじゃだめだった
最初からやり直そうかなと思いつつ報知
シェル云々って、もしかしてchrootの事を言いたいのか?
GUIは設定した名前や値を覚えてなくていいから便利なんだよなあ
あとスクリプトのテンプレートを生成してくれる支援系ツールとか、
コマンド生成ツールとか充実してるとありがたい。
フリーランスで検索すると引っかかる零細ITがやっているフリーランスのサイトはだめだ。
高額に見せているけど実際は50万前後
JIET加入した方がいいよ。案件は毎日千件以上末端価格は60万円 平凡な稼働時間の80万円の案件もある。
ユー子も求人をだしてる。名刺も渡せる。ユー子に名刺が渡せるんだぞ。夢のようだ
それらの案件まさぐってHPで転売していたのが零細ITがやるフリーランスサイト
473非決定性名無しさん2017/08/03(木) 15:21:30.71
JIETに加入すれば誰でも3次60万からスタートだ。フリーランスのサイトをやってる
自称エージェントもそこから案件情報を取得しきてる。サイトで60万で釣って40万から55万の
間でやらしている。
446非決定性名無しさん2017/08/02(水) 22:12:48.95
JIETに毎月5千円払えば３次から入場できるだろ？
高額をうたうフリーランスのサイトはだいたい５次から４５万円
JIETで閲覧応募できる末端価格からさらに搾取するのが高額をみせつけるフリーランスサイトでした
高額案件をみせつけるフリーランスサイトも案件の取得はJIETでした
自称エージェントはJIETから流れてくる案件を転売してるだけだった。
JIETに加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む
コンフィグの設定はプログラミングと違って新たな発見とかがないから
苦痛だな。
俺はVM上でテストしてるよ
失敗したり挙動が怪しくなってもスナップショット機能ですぐ元に戻せるから
色んなことを気楽に試せるようになると思う
まあインフラって「動いて当然」だから、必然的に枯れた技術と豊富なノウハウの世界になるのはしゃーない
ただ、“落とさない技術”とか“落ちたときになんとかする技術”とかは、知ってると良いこといっぱいあるよん
テーブルの作成とデータ投入とマイグレーションってどうすればいいんだ
でもdockerはよくわからんからダメってお客が多くて運用ではイマイチ使えない
入ってなきゃいけないはずなんだが、それは本当にDockerか？
エディタとランタイムはローカルの使ってる
ローカルJDK+gradle+好きなエディタ
ローカル.NET+cake+好きなエディタ
サーバーはcomposeでお手軽に構築
ユニットテストはビルドから全部フレッシュなコンテナでやってるよ
仮想化原理主義とかいうとVagrantも仮想化なんで
それをいうのならアプリケーションコンテナ原理主義でしょ？
> エディタとランタイムはローカルの使ってる
略
> ユニットテストはビルドから全部フレッシュなコンテナでやってるよ
言葉の定義の問題だけど、それを俺は開発環境とは呼ばないんだよな
だってその環境で開発してるわけじゃないから。
ユニットテストの実行環境
そしてもう一つ。CIとしてコンテナでユニットテストを
動かすってのはありなんだけど、（俺の定義での）開発環境として
ユニットテストを動かすのは大変じゃないか？
俺の定義での開発環境のユニットテストっていうのは
例えばクラスを一ついじった時に、それを保存したタイミングなどで
そのクラスだけのテストを実行したりすること
言い換えるとテキストエディタやIDEからユニットテストを実行するってこと
不可能じゃないと思うけど、そこらへんを整えてくれてるものはないと思うんで
労力を考えるとDockerを使うのは全体のテストを実行するだけでよいCIのユニットテストに限定される
よってユニットテストであっても開発環境としてDockerを使うのは大変であるというのが結論
開発環境だとデバッグのための機能を有効にしたりするしさ。
単に開発で使うサーバーの実行環境として使うのは楽だけどね。
そのお客の感覚はかなり正しいと思うけどな。
少なくとも今のdockerの段階だと。
デフォルト設定が吟味されてて多くの場合でオプション不要
手軽に細かくカスタマイズもできる
オフィシャルでセキュリティ的に安全
頻繁にメンテナンスされる
そんなRolesが大量に手軽に手に入るなら個人的にはDockerは要らないかな
将来を考えたら根幹に関わる部分で複雑な事はやって欲しくないと思うわな
dockerに限ったことじゃないが、遅かれ早かれ陳腐化する訳だし
枯れた手法と比べて明確なメリットがなきゃ導入しない方が良い
手早くスタートアップして頻繁にビジネスに変化があると見込まれるなら安定感はそれほど優先度の高い項目じゃない
何でもかんでも枯れてる安定したものがいいってところで思考停止してる人が多すぎる
> 将来を考えたら根幹に関わる部分で複雑な事はやって欲しくないと思うわな
じゃあ、そこで前提として
今より複雑か、簡単かという話が必要になる。
根幹に関わる部分は複雑になっている。
これがDocker使うと複雑なものが簡単になる。
これを否定するならば、なぜDockerを使うと
複雑になるのかを説明しなければいけない。
その時に「俺はDocker知らん。勉強しなければ
いけないから複雑なんだ」では答えになっていない。
もちろんDocker使うと複雑なものが簡単になるというのは説明可能
ベキトウセイとかシェルスクリプトで十分じゃん
apt-get install -y hoge
これだけでもベキトウだよ
なんでわざわざあんなわかりにくい大げさなyml書かなきゃいけないのさ？
逆に言えば書けるならそれでいいという話になるが
プレイブックは誰にでもメンテナンスしやすいものだっていうansible側の広告が刷り込まれて先入観があるんじゃないかな？
実際あんなのメンテナンスするのわかりにくいし大変だよ
例えば鍵とかリポジトリ登録するところとかシェルで書くときはこうだなってのわかってないと絶対プレイブックも書けない
シェルがわからない非エンジニアでもプレイブックならわかるって本気でみんな考えてるのかな
その感覚よくわからんわ
自由に導入したらいいよ
明確なメリットがあれば俺も使うし
>>64
複雑というのは習得に掛かった時間と思って貰えたらいい
dockerで用意された環境を立ち上げる事は簡単だが
その用意された環境を構築する作業も簡単とは俺は決して言えない
Dockerを使わずに鯖運用するスキルを身につけるコストのほうが高いと思うぞ
> 複雑というのは習得に掛かった時間と思って貰えたらいい
何を言ってるんだ？
例えば、未経験者にとっては習得に時間がかかると思うが
習得に時間がかかる＝複雑だというのなら、
お前は
未経験者「俺の知らないことだかけ。複雑ですね。導入する価値なし」
って言われて納得するのか？
まあ大前提として、一番重要なデータ部分と設定のドキュメント化が
しっかりして残されてる事が最低限だよな。
リポジトリから拾ってきたな様なのにはその辺がブラックボックスなのが
少なくないがw
逆に言えば、それさえ明確にきちんと残されているなら、仮にdockerが
陳腐化して消え去っても移行は全然難しくない。
手順書などというメンテナンスされない傾向にある
ドキュメントではなく、Dockerfileという簡単な
設定ファイルで書くことができるってこと
だからブラックボックスにはならない
でここから二種類の人間に別れる。Dockerfileは
すごく簡単なファイルなんだが、
未経験者の新人ややる気のないSEのような
Dockerfileが読めない人間は、勉強したくないと駄々をこねる
なまじ年を取ったやつが偉そうに複雑だから使えないとか
破綻したことを言い出すわけだ
一応言っておくけどdocker不要論者じゃないからね
メリットがあるなら使えばいいと言ってる
要求が上がるにつれて自然と選択肢に上がるんだし
ssh => winrm
apt/yum => chocolatey
docker => windows server container
ansible => powershell DSC
vagrant => vagrant
これでいいのか？
guiインストーラーしかないマイナーなアプリのインストールとかどうやって自動化するんだ…
誰も使ってなくて相談できねぇ
わざわざ独自にGUIインストーラー実装してるような変わり者ならしょうがないが。
例えばLinuxコマンド一切叩け無い人や、
素でサーバ構築した経験がない人がいたとして、
DockerfileやVagrantfileの書き方や、
dockerコマンド、vagrantコマンドだけ覚えた場合でも構築
出来るようになるの？
特にシンボルと配列のキーを指定する記法とがごっちゃになるし、
設定項目と値の間に = 要るのか要らんのかの基準がよくわからない
linux未経験だったけど普通に使えてるよ
プログラムのAPI覚えるのと変わらん
変数 = 値
= が無いのは、メソッド名と引数。
puts :abc
#=> abc
メソッド名(引数)の、( ) を省略できる。
常に省略できるかどうかは、知らないけど
AnsibleとDockerはやりたいことに対して実現方法が大げさすぎる
実OS上でアプリ開発すればいいし、
Windows もWSLでUbuntuが使えるようになったし、
今の時代でもVagrantを使う必要があるのか悩む
でもMacに慣れた後Linuxやるとめんどくさい
brewだと特に苦労せずサクサク新しいバージョンのパッケージが入る
Linuxはいちいちリポジトリや鍵登録せんとあかん
メンドくさくて環境汚れてもMacでいいやという気持ちになる
だからそこでDockerを使うんだよ。
Docker使えば環境を汚さずに（消したいときはコマンド一つ叩くだけ）
好きなバージョンを入れられる。
むしろ docker rmi でいつでも気兼ねなくサクサク消せるのがメリットなんだと割り切っちゃえ
え？ いらなくね？
普通に最新のDocker for Windowsインストールして
docker ps できたよ。
docker machine使わないといけない技術的な理由思いつかないし
ほら、なにもいない
docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
docker-machine config
Error: No machine name(s) specified and no "default" machine exists
Windows 7はNGってこと？
も使えるの？
正直Linuxマシンは手動ゴリ押しでもDockerでも構築できるっちゃできる。
だけどこれらのOSとかAndroidとかLinux以外が簡単に構築できたらめっちゃ
便利やん。
Winはその・・・お察しだな。
補足:
cisco, YAMAHAとかのOS独自のコマンド操作とかGUI操作のものを、
RubyとかYMLとかDockerfileの文法に変換して統一出来たらいいなってこと。
AnsibleにIOSのモジュールがあるっぽいよ
https://gblogs.cisco.com/jp/2016/11/ansible-ios-related/
リアリインフラは触らないから使ったことはないが
historyからシェルスクリプトにしておけば、
DockerやChefと同じことできるんじゃないの?
全く同じサーバが1枚のフャ@イルで構築でｂｫるじゃん。
レジストリも充実してるよ
あとDockerって慣れてくるとDockerfileは自分では殆ど書かなくなってrunとかcomposeがメインになってくるんだわ
だからシェルスクリプトとじゃ比較にすらならない
便利かもしれん。
ホスト側の管理はUIあったほうがやりやすいからな。
100〜のスレッドの続きを読む