  |
はてなキーワード: dockerとは
'サービス 開発 リモートワーク 提供 機械学習 プロダクト ソリューション 大規模 技術 要件 する チーム 企画 運用 設計 検索 ため 推進 製品 活用 改善 通信 投資 terraform アーキテクチャ フレームワーク ポジション データ 用い cto プラットフォーム gcp 課題 ビジネス 備考 リーダー scala クラウドサービス 配信 利用 リード 特化 github 処理 ユーザー ci js パーソルクロステクノロジー 新規 喫煙 月額 ai 提案 ビッグデータ クラウド 検知 仕様 スクラム 受注 施策 連携 マーケティング 展開 主体的 インフラ メディア フレックスタイム制 翻訳 広告 社会 事業内容 年俸制 行動 対する マネジメント 音声 自然言語処理 東京メトロ django レコメンド 保養 docker 購入 分析 go メンバー 解決 フルフレックス 検討 jira sas ステークホルダー 折衝 基本給 定義 創業 表彰 新橋駅 インターネット ansible'
'制作 応募 ます 未経験 ゲーム 月給 研修 案件 ください あり 完全 ok 交通費 歓迎 java 土日 アクセンチュア 試用期間 希望 契約社員 です たい テスト 休み スキル ヶ月 電話 エンジニア 年収 まで ませ 実績 あなた 名古屋 住宅手当 スクール ブランク 弊社 php サーバー 面接 net お客様 紹介 vb 豊富 up タイトル 経験者 チェンジ 原則 から 営業 夏季休暇 ディビジョン 不問 ses 全額支給 step ドローン ござい 許可 つけ 相談 みなとみらい 言語 か月 定期的 書類 好き 気軽 製造 内定 当社 活躍 db また 昇給 週休 教育 全員 prevent 面談 デバイス ソクコム 内容 分野 人数 cobol 雇用 策定 先輩 有料 連絡 求人 知識 安心 農業 残業 産前産後休暇'
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 1651 | 男性の立場で育児を本気でやったのでマニュアル化した（新生児期） - ひまじんの日記 | takumif.hatenablog.com |
| 1272 | 【テンプレ付】chatgptを使ってツールの要件定義をしたら工数が40時間→4時間になった - みんなのシステム企画 | ripurun.com |
| 1234 | SF小説好き1480名に聞いた「絶対に読んどけ」っていうSF小説ランキング - 俺だってヒーローになりてえよ | www.orehero.net |
| 876 | なぜ雑談が重要か - stmn tech blog | tech.stmn.co.jp |
| 849 | 半年くらい子育てしてみた感想 | kinoppyd.dev |
| 844 | コラム53：迷惑はかけてもいい｜運営委員・相談員のコラム｜学習相談室｜東京大学大学院法学政治学研究科・法学部 | www.j.u-tokyo.ac.jp |
| 755 | 家族が亡くなった直後に避けたい5つの行動 | www.ht-tax.or.jp |
| 693 | 『日中韓共通語彙集』pdf | tcvd-asia.com |
| 681 | アスパルテームの安全性 畝山智香子さんに聞く | foocom.net |
| 653 | あだち充『タッチ』を精読する。浅倉南はほんとうは何を考えていたのか。 | somethingorange.jp |
| 638 | 山下達郎氏が松尾潔との契約の解除に同意した件について│おとましぐらの音楽ブログ | mujintoudisk.com |
| 619 | コンピュータ基礎講座 第1回 | jp.fujitsu.com |
| 619 | 熱中症予防に「前腕冷却」「手のひら冷却」が効果的 アスリートも実践 | weathernews.jp |
| 594 | 株式譲渡のご案内【VISUAL ARTS BLOG】 | visual-arts.jp |
| 538 | 徐々に高度になるリングバッファの話 - Software Transactional Memo | kumagi.hatenablog.com |
| 527 | クビになった青い鳥のイラスト | www.irasutoya.com |
| 515 | なぜ、ただのアニメやゲームが人を救うのか、宗教的に説明するよ。 - Something Orange | somethingorange.jp |
| 495 | 文章校正支援ツール ｜ 無限ツールズ | mugen-tools.com |
| 492 | 5ch.net のサポート終了と Talk 対応に関するお知らせ ｜ 株式会社ジェーン | janesoft.net |
| 481 | 30～40代男女の7割が、Vtuberが配信している動画を全く見ないと回答。ほぼ毎日見ているのは14%【Vtuberに関するアンケート】 | sheepdog.co.jp |
| 478 | 朝日新聞社内でジャニーズ報道を仕切る「ジャニ担」の影響力｜SlowNews ｜ スローニュース | slownews.com |
| 477 | コンピュータ講座 応用編 第1回 | jp.fujitsu.com |
| 472 | きれいなコードを書けという話について - Software Transactional Memo | kumagi.hatenablog.com |
| 470 | ツクツクボウシの鳴き声がパートごとに異なる意味を持つことを初実証 ｜ 研究成果 ｜ 九州大学（KYUSHU UNIVERSITY） | www.kyushu-u.ac.jp |
| 457 | フリーランス・個人事業主は知っておきたい新たな選択肢「マイクロ法人」とは？ | www.ht-tax.or.jp |
| 456 | Dockerのポートマッピングのデフォルト設定は危ない - JUNのブログ | jun-networks.hatenablog.com |
| 451 | 【格ゲー】『俺を獲れ』ウメハラがデータ収集のGeminiさんに厳しい対応をしていた理由が判明！「オレ自身が自分のプレイをデータ収集に近い感じでSF4から見てた」「だからこそ言いたい。メチャレベル低いすよって」 ｜ まじっく ざ げーまー - ゲームのレビュー、攻略、情報サイト | mtg60.com |
| 448 | TBS金曜ドラマ『トリリオンゲーム』のハッキングシーン舞台裏 - 株式会社リチェルカセキュリティ | ricsec.co.jp |
| 426 | 「20 年の IT の遅れを取り戻せる手応えを感じる」 文部科学省の Slack 導入 | slack.com |
| 397 | ついに山下達郎の晩節が汚れたw（松尾潔のジャニーズ批判） - まいかのあーだこーだ：楽天ブログ | plaza.rakuten.co.jp |
各分野ではそれぞれ数年に一度くらいかも知れんけど、一人の人間が同時に関わっている分野がいくつもあるわけで、それらの掛け算で結局はもっと頻繁に新しいことに対応していく必要があるでしょ。
たとえばGitHub自体の変化はそれほどでもなくても、まさかGitHubだけを使って仕事をしている人がいるわけじゃないだろうし、それは言語にせよ何にせよ同じなわけで。
言語が PHP → Perl → Ruby → Python と変わるのと、 SVN → GitHub の変化と、AWSとかのクラウド環境の変化と、Dockerなどの仮想環境の変化と、OSやエディタの変化と、そういうのが並行して起こっているわけで。たとえば C/C++ をずっとやっている人だって規格や処理系自体の変化についていかなくちゃいけないし。
最近は最前線から離れててあんまり追えてないけど、現役のときの2008年くらいから10年くらいの間で、仕事のやり方や設計の考え方が大きく変わったIT技術要素で、いまぱっと思い浮かぶのはこんな感じかな。
分野にもよるし、調査して試作した結果自分の業務には採用しなかった技術とかもある。流行ると思って使えるようになったけど流行らなかった技術を入れるとたぶんもっとある。
あと、新機種が出てOSが新しくなったり、ミドルウェアの新バージョン対応、テスト手法の進化もけっこうカロリー高いけどここには書いてない。
「自分はフロントエンド専門でReactしかやらない」みたいに分野を絞れば大分減るけど、その技術が何年持つかわからないから普通はリスクヘッジのために他の技術も齧らざるを得ないし、バックエンドとかの人と議論するのに結局他分野の知識もそれなりに必要。
NoSQL(memcached, Redis, Cassandra)
クラウドアーキテクチャ、XaaS(AWS, Google Cloud, MicrosoftAzure)
CI/CD(Travis CI, CircleCI, Jenkins)
トランスパイラ(Browserify, webpack, CoffeeScript, TypeScript)
型システム(Rust, TypeScript, Haskell)
オーケストレーション(Ansible, Kubernetes, Terraform)
機械学習(Python, MATLAB, 線形代数等数学知識)
SPA(React, AngularJS, Ember.js, Vue.js)
3Dゲームエンジン(Unreal Engine無償化、Unity5)の他分野への普及
GraphQL
機械学習ライブラリ(Tensorflow, PyTorch, Chainer)
Jupyter Notebook
NFT
Next.js を勉強中なんだが、Docker で negix (web) と Next.js のコンテナを起動していて、Next.js から web の API (ttp://127.0.0.1:8080 とする) を fetch するときに、Next.js 側がサーバーコンポーネントの場合 URI に ttp://127.0.0.1:8080 を指定すると fetch failed する。ttp://host.docker.internal:8080 じゃないと駄目だった。
やられた。これで何日持っていかれたのか。
クライアントコンポーネントだと ttp://127.0.0.1:8080 で普通に動作する。サーバーコンポーネントでも httpbin.org などの他の API は正常に動作する。web 側で Access-Controll-Allow-Origin も設定されている。だから、まー謎だった。エラーメッセージも全然詳しくねーし。
Twitter では死んだふりをしてるので取り急ぎここにメモ。SNS に復活することがあったらあとで消す。
参考
ttps://qiita.com/YasuhaF/items/8a72d2898736fb60315f
もともとゲーム用に買ったGPUなのでRTX3070。8GBだとたまに足りなくなりがちだけど、意外と大きめの画像でも出せることに気づいたのでまだダマシダマシ使ってます。
あんまり関係ないけどCPUまわりは3900Xにメモリ64GBなので、モリモリ仕様です。
SSDはSATAだとモデルの読み込みで頭打ちするので注意。とはいっても、最初のモデル読み込みだけなのでモデル切り替えを毎回やるとかでなければ別に困らないので、NVMeじゃなくてSATAに置いてます。
OSはWindows11の上にWSLでUbuntu入れてNVIDIA docker環境にしてます。これするだけでWindowsでも爆速になった。RADEONでもWSLにするとはやくなったりしそう。
買い換えは考えてるけどCPUはまだ困ってないので買い換えるつもりないとして、GPUはVRAM24GBぐらいでお手ごろ価格のが出るの待ちです。スライドで4070に買い換えるメリットがあんまり無い。
この期間に、様々なプロジェクトに関わり、多くのことを学びました。
今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います。
はてなでは、主にRuby on Railsを使ってWebアプリケーションを開発していました。
はてなブログやはてなブックマークなどの有名なサービスはもちろん、社内向けのツールや新規事業のプロトタイプもRailsで作っていました。
Railsは、高速に開発できるというメリットがありますが、それと同時にコードの品質やパフォーマンスにも気を配る必要があります。
私は、テストやリファクタリング、コードレビューなどの技術的なプラクティスを積極的に取り入れることで、Railsの開発をより効率的で安全に行う方法を学びました。
例えば、私が担当したプロジェクトでは、RSpecやRuboCopといったツールを使ってテストカバレッジやコード規約をチェックし、GitHub ActionsやCircleCIといったサービスを使って自動化しました。
また、Pull RequestやPair Programmingといった方法を使ってコードのレビューを行い、バグや改善点を見つけたり、知識やノウハウを共有したりしました。
また、はてなでは、AWSやGCPなどのクラウドサービスを活用してインフラを構築していました。
私は、DockerやKubernetes、Terraformなどのツールを使って、コンテナ化やオーケストレーション、インフラストラクチャ・アズ・コードなどの技術を実践しました。
これらの技術は、開発環境と本番環境の差異を減らし、デプロイやスケーリングを容易にするという利点がありますが、それと同時に複雑さやトラブルシューティングの難しさも増します。
私は、モニタリングやロギング、アラートなどの技術的な仕組みを整備することで、インフラの運用をより安定的で信頼性の高いものにする方法を学びました。
例えば、私が関わったプロジェクトでは、DatadogやCloudWatchといったサービスを使ってシステムの状態やパフォーマンスを監視し、SlackやPagerDutyといったサービスを使って異常や警告を通知しました。
また、ElasticsearchやFluentdといったツールを使ってログの収集や分析を行い、原因究明や改善策の検討に役立てました。
## チームでの協働
はてなでエンジニアとして働くことで、私は多くの技術的なスキルや知識を身につけることができました。
しかし、それ以上に大切だったのは、チームで協力して問題を解決することでした。
はてなでは、エンジニアだけでなくデザイナーやプロダクトマネージャーなどの他職種とも連携してプロジェクトを進めることが多かったです。
私は、コミュニケーションやフィードバック、ドキュメンテーションなどの技術的ではないスキルも重要だと感じました。
私は、自分の意見や提案を積極的に発信することで、プロダクトやサービスの品質や価値を高める方法を学びました。
例えば、私が参加したプロジェクトでは、SlackやZoomといったツールを使って日常的に情報交換や相談を行い、BacklogやJiraといったツールを使ってタスク管理や進捗報告を行いました。
また、FigmaやMiroといったツールを使ってデザインやアイデアの共有やフィードバックを行いました。
私は、はてなでエンジニアとして働くことがとても楽しく充実していました。
しかし、私は自分のキャリアについて考える中で、新しい挑戦をしたいという気持ちが強くなりました。
私は、自分の興味や関心のある分野にもっと深く没頭したいと思いました。
## おわりに
彼らに感謝する気持ちを込めて、このエントリーを書き終えたいと思います。
Dockerは有償化に伴い、タダ乗りユーザーがグズグズ文句言いながら結局よそに逃げて、ごく一部の心あるユーザーとともに表舞台から姿を消しつつある。
Twitterは「逃げる先のないDocker」みたいなもんじゃないかと思った。
Twitterに競合となるSNSは多々あっても、代替となるサービスは殆ど無い。
blueskyとかまだ始まったばっかりだし、今後どうなるかわからない小規模のサービスばかりだ。
というわけで、今後どうなるか非常に興味深い。
立ち上げ時からビジネスを念頭に置いて開発された代替サービスに取って代わられてDockerの二の舞になるのか、
逃げる先が一向に育たず多少ユーザーが減るぐらいで残ったユーザーがグズグズ文句言いながらとどまるのか、群雄割拠なカオスになるのか。
Dockerは、開発から運用まで一貫した環境を提供することで、開発者の作業負担を減らすという大きな利点があります。また、仮想マシンと比較してリソースの使用効率が高いため、エコとも言えます。
ただし、確かにDockerには一定のオーバーヘッドが存在します。これは、DockerがゲストOSを持たずに、ホストOSのカーネルを共有して動作するためです。それにより、アプリケーションの実行に必要なリソースが追加で必要になり、パフォーマンスに影響を及ぼす場合があります。
また、Dockerを利用する際の設定や構成によってもパフォーマンスは大きく変わります。例えば、Dockerのネットワーキングやストレージの設定、またホストOSとの互換性など、考慮すべき要素は多数存在します。
あなたの現在の状況について具体的に述べると、FESSのクローリングが重いという問題は、Dockerのオーバーヘッドだけが原因ではない可能性があります。Dockerコンテナ内のFESSやJVMの設定、ホストマシンのリソース割り当て、ネットワークやストレージの設定など、様々な要因が絡んでいるかもしれません。
また、Dockerのログ出力が多いと感じる場合も、実際のところはFESSやDockerの設定によるものかもしれません。ログの出力レベルを調整することで、必要な情報だけを出力するように設定することも可能です。
しかし、これらの設定を調整するためには一定の知識と経験が必要で、それがなければ素直にネイティブ環境での構築が良い選択かもしれません。結局のところ、どの方法が最善かは具体的な要件や状況によります。
このような状況に直面した際には、パフォーマンスの問題を具体的に分析し、適切な解決策を見つけるためにパフォーマンスモニタリングやロギングツールを使用することをお勧めします。それにより、問題の原因を特定し、適切な対策を講じることが可能になります。
たとえば、Dockerが高いCPU使用率を示している場合、それはコンテナ内のアプリケーション（この場合はFESS）が高いリソースを消費している可能性があります。その場合、アプリケーションの設定や実行パラメータを調整することで改善できるかもしれません。
また、Dockerコンテナのリソース制限を調整することも検討できます。Dockerは、コンテナに割り当てるCPUやメモリの量を制限する機能を提供しています。これにより、他のプロセスに影響を与えることなく、特定のコンテナのリソース使用量を管理することが可能です。
さらに、Dockerのボリュームやネットワーク設定が適切であるかを確認することも重要です。不適切な設定はパフォーマンスに悪影響を及ぼす可能性があります。たとえば、ファイルI/Oのパフォーマンスは、ホストOSとコンテナ間でデータを共有する方法に大きく依存します。そのため、適切なボリュームの設定や、パフォーマンスを向上させるための最適化オプションが適用されていることを確認することが重要です。
最後に、Docker自体のアップデートもパフォーマンス改善に寄与する場合があります。最新のDockerエンジンには、パフォーマンスを改善するための修正や改善が含まれていることがあります。
これらの要素を考慮に入れ、Dockerのパフォーマンスを最適化する方法を探すことができます。ただし、これらすべてを試してもパフォーマンスが改善しない場合や、必要な知識や時間が不足している場合は、Dockerを使用しないネイティブな環境での構築が最善の選択であるかもしれません。
そりゃそうなんだろうけども。そんなに？
追記：FESSをOSに直接インストールするのに参考にしたというよりコピペさせてもらったのは以下の記事
https://qiita.com/hyoshiaki/items/598127fe30b94bd82b6e
半年前に辞めてしまった前任者から存在すら知らされていない客先のメールアカウントが必要になった。
無いならないであきらめてもらえるんだが、僕は優しいのでファイルサーバに無いかくらいは確認しようと思ったが
なので昔うっすら使ったことのあるFESSで全文検索しよう、多分txtかxlsだろう。
とウェブサイトで構築方法を見ると今はDockerで動かすのが良いらしい。何がいいか知らんが。
ドキュメントに従いインストールし、なんとかクローリングまで実行できたが、重い。重すぎる。
サブフォルダ無しで100ファイルくらいのフォルダでも2，3日回しても終わってない。
CPU使用率が50%超えてるんだよ！ってログが出まくっている。そのログ出力無駄じゃない？
使えないかー、とググってみるとDockerではなく素で構築する方法を有志の方が書かれているのを発見。
それに従い構築。するとサブフォルダ5階層くらいのフォルダが3分くらいで終了。
ログにCPUがーっていうのも出てないわけではないが、明らかに少ない。なんだこれ。
Dockerは構築楽らしいしVMよりエコだっていうのは聞いたことあるんですが、
素のOSに入れるよりはどうしてもオーバーヘッドあるんですかね、というのが今回の教訓でありました。
