サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ブラックフライデー
zaki-hmkc.hatenablog.com
2023-08-11: RHEL系VMの起動エラーの対応について追記 新しく購入したMINISFORUM NAB6に自宅検証マシンとして仮想化プラットフォームのProxmox VEをセットアップしたのでその記録。 上に乗せてるのはサイズ比較用キーボードのキートップストラップ。 🤡 Proxmox Virtual Environment インストール ログイン apt設定 NAS設定(NFS) 内蔵ストレージ追加 VM作成おためし (RHEL9) ESXiからVMをインポート NetworkManager (Fedora) interfaces (Debian) netplan (Ubuntu) ドキュメント サイズ感(おまけ) 🤡 先日ふと見つけた小型PCが良さそうと思ったら、意外と周りでみんな購入してたみたいなので便乗して購入。 デバイスそのものはレビュー記事があるのでそちら参照。
Windows Terminalの「新しいタブ(ターミナル)を開く」に、いつもsshで接続して作業するメインのホストにシェルを起動する。 設定箇所 タブを開く新しい項目を追加する 追加項目のコマンドにsshを指定する 公開鍵認証設定してパスワードを聞かれないようにする(OpenSSH一般) パスフレーズなしキーペア作成と設定 -i で秘密鍵ファイル指定でssh .ssh/configに鍵ファイルパス指定 Windows Terminalの設定 アイコン 参考 設定箇所 "list": [ { // Make changes here to the powershell.exe profile "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "name": "Windows PowerShell", "commandline": "powe
年末くらいから、メインの作業用Linuxマシン(この1台のみ)にVS CodeのRemote DevelopmentでSSHアクセスすると一定時間高負荷状態が続いていたので、なんとかならないかと原因調査した結果。 なお、クライアント側のVS CodeはどのPCから接続しても、特定の接続先Linuxマシンのみで高負荷になっていたので、VS CodeをインストールしているPC側の問題ではなかった ないだろうと見当をつけて調査。 VS Code version: 1.52.1 VS CodeのRemote SSHでnodeプロセスが高負荷になる 大量のreportファイル 原因 watchの除外設定 (余談) なぜこんなにvenvがあるのか まとめ VS CodeのRemote SSHでnodeプロセスが高負荷になる Remote Development SSHでアクセスした時のtopの状態がこ
クラウドリソースの使用料やサブスクリプションの費用無しに利用することができるOpenShiftを4つ紹介します。 他にもあるかもしれませんが、私が個人環境で触ったことがあるのがこの4つという話です。 用途に応じてお試ししてみてね。 (独断と偏見で難易度(手軽さ):易→難の順に並べています) (1) Learn OpenShift (2) IBM Open Labs 参考情報 (3) CodeReady Containers 導入例 (on CentOS 7) 導入例 (on Windows 10 pro) --enable-experimental-features 参考情報 (4) OKD on ベアメタル他 参考情報 バージョンその他諸々は、2020.09.23時点のものです。 (1) Learn OpenShift OpenShiftバージョン: 3.11 ~ 4.5 ユーザー登録:
以前「コンテナ若葉マーク」で「コンテナ環境ではIPアドレスじゃなくてコンテナ名を使って通信しろ!(IPアドレスは意識するな!)」みたいなことを話したりしたことあったんですが、何らかの理由でコンテナ名(ホスト名)でなくIPアドレスを使って(イコールIPアドレスを固定して)コンテナを使いたい場合について。 コンテナ単体で固定IPアドレスを使いたいユースケースはさすがに無いと思うので、複数のコンテナをデプロイしてお互いのコンテナ間通信の際にIPアドレスを固定したい、という場合について、Docker単体(docker実行)の場合と、Docker Compose使用時それぞれについて説明します。 まずDocker Networkを作成してから、そのネットワーク上にコンテナをデプロイ、という構成は同じです。 Docker単体 Network作成 ネットワークのみ指定のコンテナ IPアドレス指定 Doc
playbook内のtask定義にtagを設定しておくことで、指定tagのtaskのみ実行したり、逆に指定tagのtaskを除外してansible-playbookを実行することができます。 開発中のtaskのみピンポイントで実行したい場合や、逆に、共有のDBのデータを更新したりするtaskはほかのユーザーやチームと調整してからでないと実行が難しかったり、Blue-Greenデプロイメントの実装で環境Aの機能をオフにしてもう片方の環境Bをオンにするような処理だけど開発中は環境Bだけ確認したかったり、大量データのダウンロードや冪等の確認を伴い処理に時間がかかるため開発中は実行したくないなど特定のtaskは実行したくない場合に利用できます。 また、特殊tagとして、常に実行するalwaysと実行しないneverというtagが予約語として用意されています。 neverは特に「通常は実行したくない
良い感じのタイトルにならないやつ 構成 よくある話だと思うけど、2つのnicを持っているLinuxマシンに対して、internal segment側のマシンのゲートウェイとして動作させる、というやつ。 実は大昔に一度構築したけど、その時のメモがないので再構築したというお話。 図中internal segmentのマシンから、public segmentおよびインターネットへアクセスできるようにする設定を行います。 2nic持ってる対象のLinuxは、CentOS 7.5 1804 minimalでセットアップしてあります。 概要 ルーターLinux ens224(172.16.0.0/23)からのパケットをens192(192.168.0.0/24)へ流す DNSも自身で稼働して172.16.0.0/23からの問い合わせに応答・または上位へ問い合わせ nic毎の設定は以下の通り 項目 ni
2年近くproxyすらないネットに繋がらない環境にいて、少し前にようやくパブリッククラウドの自由ないんたーねっとを手に入れたぜうっひょーと思ったら、今度はついにproxy環境での検証をすることになったので、自宅ラボにも似たような構成作れないか、Squidでproxyサーバーを立ててみました。 www.squid-cache.org せっかくなのでDockerで。 完成予定図はこんな感じ。 Squidを手作業で動かしてみる on Docker 制限ネットワークからproxy設定してwebアクセス Squidバージョン イメージ作成 Dockerfile build run Docker Hubから 課題 (ログ) stdoutへ書き込み不可 回避策 (9/6追記) おまけ (9/6追記) Squidを手作業で動かしてみる on Docker なんとなくCentOS 7で、検証用コンテナを起動
オンプレ環境だと必ずと言っていいほど存在する「エクセルのIPアドレス管理台帳」、なんやかやで私も自宅の環境でもスプレッドシート(Excelではない笑)に記入しつつ運用してました。 で、業務で最近NetBoxというアドレス管理などを行うIPAMツールを使うことが増えたので、勉強がてら自宅にも導入してみました。 github.com NetBoxって何 インストール 環境 NetBoxインストール ログイン 管理方針 (仮) Devices Sites Device Roles Manufacturers Device Types Deviceの登録 インタフェースとIPアドレス設定 (デバイスから作成) Virtual Machines Cluster Types Clusters VMの登録 インタフェースとIPアドレス設定 (VMから作成) IPアドレス作成 (IP Addressesか
シングルバイナリで簡単・軽量で動くKubernetesディストリビューション「k0s」が出たということで、手元で試してみた。 新しい Kuberentes distro, #k0s が OSSで公開されました! 軽量、ワンバイナリ、Intel/ARM対応、アップデートも簡単! チェックしてみてください!https://t.co/B4gBUPWau2— Mirantis Japan (@Mirantis_JP) 2020年11月13日 k0sproject.io github.com www.publickey1.jp バイナリを入手 version help 設定 起動 kubeconfig クラスタの状態(1) node token作る workerをクラスタに追加 クラスタの状態(2) シングルworker構成 metrics server サンプルpod 動作させたOSはCentOS
Kialiを使ってサービスメッシュのトラフィックをチェックする。 [zaki@cloud-dev ~]$ kc get pod,deploy,svc -n istio-system -l app=kiali NAME READY STATUS RESTARTS AGE pod/kiali-d45468dc4-jlshb 1/1 Running 5 23d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/kiali 1/1 1 1 23d NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kiali ClusterIP 10.104.53.76 <none> 20001/TCP 23d 環境 (追記) インストール istioctlを使ったアクセス ログインアカウント サービスメッ
昨夜~今朝でストレージ不足で成功しなかったRed Hat CodeReady ContainersでローカルOpenShift 4にチャレンジ。 必要なのはRed Hatの開発者アカウント(無料) 細かい手順は失敗編のこちら zaki-hmkc.hatenablog.com VMの準備(主にストレージ) [zaki@codeready ~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/centos-root 76G 978M 75G 2% / devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 8.9M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/sda1 10
このページを最初にブックマークしてみませんか?
『zaki work log』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く