5丁目通信(仮称)

とある5丁目で活動する還暦を過ぎたWebプログラマーの覚え書きです。それとかかってくる迷惑電話や、家業のアパート経営について。

タグ: Docker

  • ルーターをRTX-810からRTX-1300に交換した話し

    社内というか自宅のネットワーク速度を改善するために、まずはルーターを交換してみます。現在のルーターはRTX-810です。購入したのは10年前です。

    しかもRTX-810はヤフオクで落札したので、RTX-810自体は相当古いルーターとなります。ヤマハのルーターはとても安定して動くので、10年以上トラブルなしに安定して動いていました。おかげでRTX-810を他のルーターに買い替えることを全く考えていませんでした。

    今使っているフレッツ光ネクストの1Gbpsをフレッツ光クロスの10Gbpsに将来的に切り替えることを考えて、この機会にルーターも10Gbps対応でリプレースすることにしました。ヤマハ以外の安価な10Gbps対応のルーターにしようとも考えていましたが、やはりここも使い慣れたヤマハのルーターにすることにしました。今のところは10Gbpsで手に入るヤマハのルーターはギリギリRTX-1300しかありません。他のヤマハのルーターは高くて買えません。しかし、RTX-1300は自分にとってはオーバースペックなんですけど。SFPとか必要ありませんし。

    ヤマハ(YAMAHA)
    ¥151,000 (2025/03/28 14:16時点 | Amazon調べ)
    ヤマハ(Yamaha)
    ¥39,800 (2024/01/08 10:01時点 | Amazon調べ)
    ヤマハ(Yamaha)
    ¥90,753 (2025/04/01 12:38時点 | Amazon調べ)

    拠点間や法人向けルーターは、ヤマハのルーターが信頼性があってお勧めしています。私もヤマハのルーターを使っています。

    アマゾンでRTX-1300で注文して翌日にも到着しました。アマゾンのマーケットプレイスなら少し安く手に入るのですが、多少高くても念のためにプライムで注文しておきました。ものが届かないとか遅れるとかのトラブルは避けたいので。

    早速、RTX-1300の設定をしてしまいます。

    今回はRTX-810の設定ファイルを読み込ますだけでもいいのですが、10年も使っていると余計な設定が残っていますので、ここは最初からRTX-1300のWeb設定画面で設定していきます。と言いながら、NATの設定などはWebで細かい設定ができませんし、IPテーブルの設定をいちいちWebで設定していくのも面倒なので、RTX-810のconfigからNATとIPテーブルの設定だけをRTX-1300のコマンド入力で投入していきます。

    Webからプロバイダーの設定をしてLANケーブルをRTX-810からRTX-1300に繋ぎ変えるだけでインターネットに一発で接続できました。だけど、ファンレスだったRTX−810に比べてRTX-1300はファンの音がうるさくなっています。ファンがあるということは、RTX-1300が壊れるのはファンからのなのでしょう。空冷ファンが付いているとことは、この酷暑の中、RTX-1300が熱くなるのが心配です。

    手間取ったのは、内部のネットワークにあるQNAPで構築しているDockerのサーバーの公開でした。これができないとお客さんがテストサイトのチェックができません。RTX-810のNATとIPフィルターの設定をRTX-1300にコマンドを投入しましたが、サーバーには繋がりません。公開するためのアドレスをネットボランチDNSで公開していたのを忘れていました。

    ネットボランチDNSの設定をしてしまいます。Webからの設定はとても簡単です。しかし、新しくネットボランチDNSを設定するとアドレスが変わってしまうのですね。お名前.comのドメインのDNSの設定で、ネットボランチDNSに紐づいている設定を新しい設定に変更しました。

    DNSの設定を待つこと30分、ようやくサーバーにアクセスできることを確認できました。その間全くアクセスができなかったので、DNSの設定かRTX-1300の設定かを切り分けるために、PCのhostsに直接IPアドレスとホスト名を設定してみました。すると正常にサーバーにアクセスできることが確認できましたので、原因はRTX−1300ではなくDNSの設定ということになりました。PINGを叩けばわかるのですが、RTX-1300の設定が間違えていないということがわかったので良しとしましょう。

    プロバイダーからのインターネットの接続で一点気になったことは、今のプロバイダーのぷららから設定されたグローバルのIPアドレスです。今まではぷららが所有するIPアドレスだったのですが、NTTドコモのIPアドレスに変わっていました。どんどんぷららの力が小さくなっていくのでしょうね。グローバルIPアドレスがどこが管理しているかどうかは、あまりこちらには影響ないですけどね。

    IPアドレスの設定などはそのままで、今回はルーターを入れ替えただけですので、ネットワーク内の機器の設定は必要ないを思われます。もしトラブルがあったら、家のもんから報告があるでしょう。特に今のところはトラブルの報告はありません。多少、ネットワークのアクセスが速くなったと言っていました。

    あと残りはIPv6での接続です。こちらは設定内容をブログに残しているので何とかなるでしょう。

    もし、ルーターを交換してそれでも効果がないと言われてしまいますと、次はプロバイダーの変更です。10年以上もプロバイダーはぷららを使っていますが、そろそろぷららから他の快適なプロバイダーに乗り換えたほうがよいかもしれません。

    その次は、フレッツ光ネクストからフレッツ光クロスへの乗り換えで、ネットワークを10Gにしてしまいましょう。しかし、10Gにするとなると、プロバイダーやルーターだけではなくネットワークに接続している機器も更新しなければいけません。インターネットが使えなくなる期間やひかり電話ことも考えなけばいけないので、フレッツ光クロスへの乗り換えは、いろいろと面倒のようです。

    LANケーブルだけはカテゴリ6Aにすべて引き直していますので、こちらは問題ありません。ただし、10Gbpsでの通信をしたことがないので、本当に使えるかはわかりません。

    追記

    IPv6での接続をしました。RTX-1300のWebの簡単設定でIPv6のIPoEを選択すれば簡単にできました。無事にカメが泳いでいます。

    IPv4はPPPoE、IPv6はIPoEでで接続しています。ぷららのIPv6接続確認サイトでもIPv6が接続されていることが確認できました。

    追記(2024年8月13日)

    みんそくでのスピードテストを上げておきます。混んでいる夜20:00頃の値です。値的には快適ですが、体感的には多少以前よりは速くなったかもという位でしょうか。

    フレッツ光ネクスト × plala(ぷらら)の測定結果の詳細

    種類IPv4接続IPv6接続
    接続方式PPPoEIPoE(v6コネクト)
    Jitter1.23ms1.22ms
    Ping7.9ms7.4ms
    下り442.26Mbps(非常に速い)664.43Mbps(超速い)
    上り579.97Mbps(超速い)576.63Mbps(超速い)
  • error: RPC failed; curl 56 HTTP/2 stream 5 was resetでgit pushができなくなった話し

    突然、git pushができなくなってGitLabのリモートリポジトリにアクセスでき亡くなってしまいました。エラーメッセージは次の通りです。

    error: RPC failed; curl 56 HTTP/2 stream 5 was reset
    send-pack: unexpected disconnect while reading sideband packet
    fatal: the remote end hung up unexpectedly

    おそらくHTTPでアクセスしないでSSHですればいいのですけど、GitLabの設定が面倒なのでやっていません。

    次に以下のサイトにしたがって、http.postBufferの値を大きくしてみます。

    次のコマンドを実行してみます。

    git config --global http.postBuffer 524288000

    結果は変わりません。

    GitLabはQNAPのContainer Stationを使ってDockerのコンテナにしていますので、docker-composeのYMLファイルにgit_max_sizeとgit_timeoutを追加しました。

    GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.and-works.com'
        gitlab_rails['gitlab_shell_ssh_port'] = 2022
        gitlab_rails['lfs_enabled'] = true
        gitlab_rails['lfs_storage_path'] = "/var/opt/gitlab/gitlab-rails/shared/lfs-objects"
        gitlab_rails['time_zone'] = 'Asia/Tokyo'
        gitlab_rails['git_max_size'] = 524288000
        gitlab_rails['git_timeout'] = 300

    参考にしたのは、いろいろ辿り着いたこちらのサイトです。

    最初、コンテナを再起動しただけではだめでした。一度GitLabのコンテナを削除してから起動しないとgit pushができませんでした。

    しかし、QNAPのContainer Stationは、コンテナを削除すると、docker-composeのYMLファイルの設定から何やかんやらすべて削除してくれますので、最小限docker-composeのYMLファイルのバックアップを取っておきましょう。私は、docker-composeのYMLファイルをGitで管理していましたので大丈夫でした。

    QNAPのContainer Stationで、最初からdocker-composeのYMLを挿入してアプリケーションを作成し直しました

    以上で、無事にgit pushができるようになりました。本当ならsshでリモートリポジトリをアクセスできるようにすれば、このような設定の必要はないかと思います。

    ただし、設定しておかしいのは、以下のようなアイコンが表示されるようになって、ボタングレーになってしまったことです。

    起動、停止、再起動はチェックボックスを選択して上のボタンでできますが、docker-composeのYMLを編集できないの難点です。いろいろ情報を漁っていますが、なかなか解決方法は見つかりません。

    著:湊川あい, 著:DQNEO
    ¥2,208 (2025/04/01 17:15時点 | Amazon調べ)
    著:リック・ウマリ, 翻訳:吉川邦夫
    ¥3,247 (2025/04/01 17:15時点 | Amazon調べ)

    追記(2023年7月20日)

    今度は別のリポジトリで次のようなエラーがSourceTreeで出て、何もリポジトリの中を参照できなくなってしまいました。

    git status fatal: not a git repository (or any of the parent directories): .git

    さて、どうしましょう。これはリモートリポジトリの問題ではなくて、ローカルのリポジトリの問題のようです。

    仕方ないので、とりあえず再度リモートリポジトリからCloneしてみます。Pushしていないファイルもありますので、トラブルのあるリポジトリは名前を変えて残しておきます。

    結果としては、このとりあえずのCloneした対応がよかったようです。Cloneしたら元に戻りました。リポジトリの内容も参照できます。そして、Pushできなかったリモートリポジトリも元通りに正常になりました。どうしてか、よくわかりません。

  • 何気ないQNAPの設定が、Dockerの開発環境大いに影響した話し

    突然、QNAPのContainerStationを利用してDockerコンテナーでのテストサーバーが動かなくなった。アクセスするとタイムアウトしてしまう。

    いくつかのテストサーバーやRedmine, GitlabをDockerコンテナーで構築して、jwilder/nginx-proxyを使ってnginxのリバースプロキシで分散させている。そして、jrcs/letsencrypt-nginx-proxy-companionでLet’sEncryptの証明書を自動的にインストールさせている。これは定番な設定である。

    jrcs/letsencrypt-nginx-proxy-companion のイメージで動いているコンテナのコンソールを見てみると、

    Verify error:Fetching http://{URL}/.well-known/acme-challenge/{ランダム文字列}

    というエラーが出力されている。上記のURLをブラウザで直接アクセスしてみると、確かにタイプアウトしていた。最後に

    likely firewall problem

    なんて言っているので、まずはヤマハのルーターを疑ってみる。ログを見てても特に問題はない。

    jwilder/nginx-proxy イメージのコンテナにログインしてnginxの設定を見ても問題なし。しかし、ここで問題があっても対応のしようがない。

    コンテナを再起動したり、QNAPを再起動したり、はたまたヤマハのルーターを再起動したり、最近QNAPにインストールしたQVR Proを停止したりとやってみたが、エラーは全く変わらない。どんどん嵌まり出す。

    半日が過ぎてほぼ諦めモードになる。QNAPのContainerStationをやめて、さくらインターネットのレンタルサーバーにテストサーバーを移行することまで考えた。

    ここでちょっと前にQNAPの設定を変えたことを思い出した。QNAPのアクセスをLAN側しかできないようにしていた。こちらは外部のアクセスをすべて遮断していた。こちらを見直す。

    以上、これだけで無事に元に戻った。QNAPのContainerStationとかヤマハのルーターの設定は、全く関係なくて、そのままでよかった。当たり前だけど、QNAP全体のセキュリティの設定が影響するので気を付けましょうという話しでした。はまり出すと、小さなことを気が付かない。

    Redmineに作業記録をつけているので、Redmineのサーバーが亡くなったらどうしようと思うのでした。

    SambaをLinuxサーバーのインストールしてファイルサーバーとして動かすよりも、サクッとQNAPを入れてしまったほうが簡単、安心、便利でおすすめ。ファイルサーバーだけではなくてIntelのCPUのQNAPなら、Dockerでいろいろとコンテナを設定してサーバーをたくさん立てられるしね。

  • インストールしているアプリケーションを整理してWindows 10 October 2020 (20H2)がようやく安定してきた話し

    Windows 10 October 2020 (20H2)にアップデートしたら、フリーズするようになったと書きましたが、ようやく安定して止まらなくなりました。どうして安定したかはわかりません。

    やったことと言えば、常駐するアプリケーションが必要なければアンインストールしたことです。ESETのInternet Securityとか、ましてChromeが原因ではありませんでした。アンインストールしたのは、Docker for Desktopとか、ソニーのデジカメの同期アプリケーション(Imaging Edgeの一連のシリーズ)です。Windows10の「コンピュータの管理」から「サービスとアプリケーション」-「サービス」で、状態が実行中で必要のなさそうなサービスをインストールさせているようなアプリケーションをアンインストールしていきました。

    これらがフリーズする原因かどうかはわかりません。なるべく不要なアプリケーションを削除していったほうがよさそうです。

    Dockerはまた必要になるので、そのときは再度インストールします。

    マイクロソフト
    ¥14,900 (2025/03/31 11:56時点 | Amazon調べ)
    マイクロソフト
    ¥21,700 (2025/03/29 08:10時点 | Amazon調べ)

    自作PC用に一番左のWindows11のパッケージを実際に購入しましたが、問題なくインストールできました。Windowsは使うPCの分だけ正しくライセンスを購入しましょう。

    追記

    Dockerは再度インストールしたけど、DockerがWindows10をフリーズさせる原因ではありませんでした。何が原因だったのかわからりません。

    言えることは、やはり一つづつアプリケーションやデバイスドライバを削除しながら、フリーズする原因を追及するしかなさそうです。フリーズしたら覚悟が必要になります。

    続きはこちらから

  • baserCMSの4対応でも古めのテーマは、新しい管理画面に対応してしないかもで注意という話し

    久しぶりにbaserCMSの案件である。

    最初、baserCMSと適当なテーマをインストールして、コンテンツを挿入して終わり、という簡単な案件だと思っていたら、そんな甘くはなかった。

    お客さんが選んだテーマは、bcColorsというテーマだった。

    bcColors(4系)

    サンプルで見せるために、DockerでbaserCMSのイメージでサイトを簡単に構築してbcColorsのテーマをインストールして見せた。ここまでは、問題無かった。

    さて、本番サーバーはユーザーの希望でエックスサーバーになるので、baserCMSの公式サイトから最新版をダウンロードしてインストールする。しかし、これが問題だった。baserCMSのDockerイメージとバージョンが違う。Dockerイメージのほうが同じ4系でも、だいぶ古いようだった。

    まずは、bcColorsが最新のbaserCMSでは動かない。トップページのスライドショーが表示されない障害があった。

    最新のbaserCMSのよくわからないところだが、管理画面のテーマ(admin-third?)が替わったようで、管理画面まわりがだいぶ変更となっている。どういう訳か管理画面ではないユーザー画面のテーマにも新しい管理画面のテーマが影響があるという、不思議な仕様となっている。

    一様回避策があったのでやってみたが、ユーザー画面の方は少しはマシになったが、完璧には動作しない。スライドショーは表示できるようになったけど、記事のプレビュー画像が、これまたどういう訳か、<img ・・・・・・ とテキストで表示されてしまう。

    記事のプレビューは、今回の案件では必要ないのでいいのだけど、問題は管理画面のオプションのリンクが動作しない。例えば次のような緑のリンクをクリックしても何も動作しない。

    bcColors以外の最初からインストールしているテーマに替えるとリンクができるようなっている。ということは、bcColorsが最新のbaserCMSに対応していないということである。

    baserCMSのユーザーフォーラムに質問を上げてみても、まだ回答がない。2日くらいであるから仕方ないかと思うが、このままでは案件も進まないので、ユーザーにはbcColors以外の新しいテーマを選んでもらう。新しいテーマで最新のbaserCMSで問題がないかをチェックして、管理画面で問題ないことも確認する。

    簡単に終わる案件だと思ったら、厄介な案件になりそう。

    追記(2020年11月11日)

    開発者の方に対応していただいた。

    詳細はbaserCMSのユーザーフォーラムを参照のこと。

  • しつこくwp-envで試してみたら、WordPressのGutenbergの再利用ブロック一覧は 10個以上表示していたので解決できた話し

    WordPressのGutenbergの再利用ブロック一覧は 10個以上表示されないという障害ですが、気になりだしたら停まらなくなりましたので、しつこくwp-envで試してみました。今度は正常に表示されていました。

    wp-envは、Dockerを使って簡単にWordpressの開発環境を作成できてしまいます。DockerとNode.jsがインストールできていれば、コマンド2発(インストールと起動)でWordpressが起動できます。詳しくはwordpress.orgのサイトを参照ください。

    https://ja.wordpress.org/team/handbook/block-editor/packages/packages-env/

    最初は、wp-envが起動したWordpressのバージョンも一緒なので、何かおかしいかわかりませんでした。気になるのはwp-envでは、Gutenbergのプラグインがインストールされていなくても、編集画面がGutenbergになっていました。そこで、自分のサイトのGutenbergを無効にしてみました。

    すると、何ということでしょう。正常に再利用ブロックが10個以上表示されるようになりました。画面はGutenbergのブロックエディタのままです。これで無事に解決です。解決方法がGutenbergプラグインを削除することなんて全く気が付きませんでした。何てオチなんでしょうか・・・。

    こう再利用ブロックを見てみると、Amazonのアフリエイト広告ブロックばかりですな。

    しかしながら、今はGutenbergのプラグインはインストールして有効にする必要はないのでしょうか? すでにWordpressにGutenbergは組み込まれていると言うことなのでしょうか? Gutenbergがリリースされてから、Gutenbergプラグインをずっとインストールをしていました。

    今度は、記事を書いている間に自動保存が動いて、ずっと更新中になってしまうというのは直っていません。こちらもこれから調べていかなければいけません。

    とりあずの回避策としては、記事を念のため一旦クリップボードにコピーしてブラウザの更新ボタンを押します。ブラウザから「サイトを再読込しますか?」という警告(Chromeの場合)が表示されますが、そのまま「再読込み」ボタンを押します。次に「バックアップから復元」ボタンが左上に出てきますので押せば元に戻ります。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

    続きはこちらから

    続きはこちらから(2020年12月23日)

    今は以下のような障害で、Gutenbergプラグインを再度インストールしています。

  • WordPressのGutenbergの再利用ブロック一覧は 10個以上表示されない障害のその後と回避策の話し

    WordPressのGutenbergの再利用ブロック一覧は 10個以上表示されない障害のその後の話しと、とりあえずの回避策の話しです。解決に至っていません。

    あれからGutenbergのソースを追ってみましたけど、10個以上表示しないようにフィルターをかけているなんてしなさそうでした。当たり前だけど。再利用ブロックの一覧を表示しているのは、以下のところでしょうか。

    packages\block-editor\src\components\inserter\hooks\use-block-types-state.js
    packages\block-editor\src\components\inserter\reusable-blocks-tab.js
    packages\block-editor\src\components\block-types-list\index.js

    それにしても、GutenbergはReactで記述されているのすね。ソースを追ってみたと言っても、Reactはあまりわかっていないので、何となくこんなことをやっているなんて感じでソースを追っています。

    今回でわかったのは、再利用ブロックはどこに格納しているかというと、投稿と同じpostのテーブルなんですね。Gutenbergからどうやって取得しているかは、

    select( 'core/block-editor' );

    が何かやっているようでした。そもそもwp.data.を付けずに、select()でどうして動いているかも、まだ理解していません。デバッグ環境を作って追っていければいいのですが、まだそこまでやっていません。

    そもそも、いちいち再利用ブロックが出てくるたびに、データベースを参照するなんてコストが高いと思うのですが、そこのところは上手くやっているのでしょうね。そうではないと、キャッシュ必須になってしまいます。

    また、自分のサイトが悪いのどうか切り分けるため、試しに新しくWordpressのサイトを立てて見ました。今回は簡単にWordpressのDockerイメージで起動します。簡単にテストでサーバーを起動するのはDockerが便利です。Dockerイメージを用意してくれると、とても助かります。

    クィックスタート: Compose と WordPress — Docker-docs-ja 17.06 ドキュメント

    結果は、やはり再利用ブロックの一覧は10個以上表示できませんでした。サイトの固有の問題ではなさそうです。ただ、再利用ブロックのインポートとエクスポートは正しく動いていました。まとめてインポート/エクスポートできないのが仕方ないのでしょうか。

    プラグインもすべて無効にしても変わりません。Gutenbergのブラグインだけでも、再利用ブロック一覧が10個以上表示できない障害が出ています。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

    こちらの障害は、Gutenbergの開発コミュニティに報告しなければいけませんかね。いろいろ報告の前段階の説明を読むと、面倒なことが書かれているのですので敷居が高そうです。

    試しに再利用ブロックを非公開したらリストに反映されずに、よく使うブロックを10個までにしておけばいいかと思いましたが、非公開にしてしまうと記事にほうに表示できなくなってしまうのでした。この回避策は使えません。

    もう一つの回避策としては、再利用ブロックのリストは新しく作成した順に10個だけ表示しているので、よく使う再利用ブロックの作成日付を新しい順になるように「すべての再利用ブロックの管理」から変更しておくことです。しかし、新しい順で11番目を使いたいときには、再度日付を更新するという面倒な作業が発生します。

    以上、全くGutenbergの再利用ブロックの一覧が10個しか出てこない問題は解決していません。

    続きはこちらから

  • Gitlabを13.3.5にアップデートした話し

    Gitlabを13.3.5にアップデートした話し

    Gitlabのシステム情報を見たら、アップデートしろよ、の警告が出ていたのでアップデートを行う。Gitlabのアップデートはさぼると厄介と思い込んでいるので、早めにアップデートを行う。アップデートしろと言われると、OSでもアプリでも何でもアップーデートしたくなってしまう性・・・。

    Dockerで動かしているので、コンテナイメージの指定を変更していく。念のために、一旦13.2.9の13.2系の最新版にしておく。そして、Gitlabの最新版である13.3.5にする。

    何でこんな面倒なことをするかというと、Gitlabのアップデートが何をやっているかが自分が理解していないことである。もしも、この途中でトラブルがあったらお手上げである。もとに戻すしか手がない。動いているバージョンをチェックして、戻せるようにそのコンテナを残しておく。

    以上で無事にGitlab13.3.5にアップデートができた。

  • SSI(SSLではないよ)に対応しようとApacheの設定に手こずった話し

    お客さんのサイトのテストサイトを自分のところで運用しています。テストサイトを運用しているのはさくらインターネットのVPSなのですが、このサーバーのOSが古くなってきたので別のサーバーに移したいと考えました。移行先はとりあえず、社内のQNAPのDockerコンテナにします。

    大量のHTMLファイルを新しいサーバーにコピーします。このサイトは構成が古く基本はHTMLファイルのみで動いています。コピーすれば移行完了と思いきや・・・・。

    そう言えば、SSIを使っていたのでした。共通のメニューやフッタが表示できません。Webブラウザでソースを見てみると、

    <!--#include virtual="/include/gnavi.html" -->

    がそのまま出力されて、読み込むべきファイルを展開していません。

    「apache ssi 有効」でGoogleさんに聞いて出てきたサイトによると、まず疑うのはSSIの設定している.htaccessを確認です。

    Options Includes

    でSSLを有効になっていることを確認します。

    これは既に設定されていました。

    もしかしたら、.htaccessが有効になっていないかも確認します。次に疑うのはhttpd.confでしょうか?

    AllowOverride All

    で有効になっていました。ファイルの改行コードがLFにしたりしました。念のためにHTTPDコンテナを再起動してみます。

    それでも動きません。

    .htaccessにrewriteの設定もしていましたので、リダイレクトができているかを確認します。

    リダイレクトできていません。もしかしたら・・・・。

    httpd -M

    をコンテナにアクセスして叩いてみると、mod_rewriteとmod_includeが出てきません。必要なモジュールを有効になっていないようです。そこでhttpd.conf、

    LoadModule include_module modules/mod_include.so
    LoadModule rewrite_module modules/mod_rewrite.so

    の2行のコメント(#)を外してモジュールを有効にします。そしてApacheを再起動します。

    無事にSSIが有効になって、メニューとフッタがインクルードファイルから展開して表示できました。単純にモジュールが有効になっていなかったの原因でした。

    以上、今回の教訓としては、

    Googleさんに聞いて出てきたサイトを、そのまま信じても解決しないよ。

    という話しでした。

    著:大竹 龍史, 著:山本 道子
    ¥2,950 (2025/04/01 13:05時点 | Amazon調べ)
    著:Piro, 編集:日経Linux
    ¥2,178 (2025/03/28 21:08時点 | Amazon調べ)
    著:三宅 英明, 著:大角 祐介
    ¥2,970 (2025/04/01 13:05時点 | Amazon調べ)
  • Dockerコンテナで動いているGitlabをアップデートしようしたら面倒くさかった話し

    自社のQNAPサーバーでGitlabをDockerコンテナを動かしているけど、バージョンアップしろ、って出てくる。赤い表示はとても気になる。

    自分でメンテナンスをしなければいけいないのはオンプレミスの面倒なところ。

    現在は12.7.6である(上の画像では13.0.0になっているけど、最初のスクリーンショットを取り忘れた)。Rubyで書かれたサイトのバージョンアップはうまく行ったためしがない。Rubyのサイトのバージョンアップをしていると、Rubyのためかサイトのためか、バージョンアップしているのかわからなくなるのが辛い。

    このままでは放っておけないので、重い腰を上げてGitlabをバージョンアップしてみる。下調べすると、とてもGitlabのバージョンアップをするのに面倒なことが書いてある。一発でバージョンアップできないようだ。Gitlabのサポートページによると、とっても簡単だと書いてあるけど、これは信じてはいけない。

    参考にしたサイトは以下のサイトである。

    それとGitlabのサポートページに書いてあるメジャーバージョンアップの項目である。

    ようするにメジャーバージョンアップは一つづつやれってこと。試しに一気にlatestにまでバージョンアップしたら、案の定動かなかった。つまり、自分のところではGitlabのサポートページに従うと、

    12.7.6 -> 12.10.0 -> 13.0.0 -> latest(13.2.1)

    と3回の作業が必要となる。12.10.0でデーターベースのPostgreSQLがバージョンしたらしくてマイナーバージョンアップでも一旦バージョンアップしなくていけないそうだ(そんなの知るか!状態)。

    念のためにその都度バックアップをとっておく。QNAPのContainerStationを使いながら、以下の操作を繰り返す。

    1. gitlab-rake gitlab:backup:create でGitlabのデータをバックアップ
    2. Gitlabコンテナ停止
    3. Gitlabコンテナ削除
    4. docker-compose.ymlのimageのバージョン書き換え
    5. Gitlabコンテナ起動
    6. Gitlab動作確認

    やることは単純だけど、これを3回繰り返すと無事に最新のGitlabにバージョンアップされた。Gitlabのサポートページの言ったとおり簡単だった?

    だけど、「データーベースのバージョンアップも途中でやれ」って、あるサイトに書かれていたけど、バージョンアップでコンテナを起動するたびに、自動的にデーターベースのマイグレーションが実行しているようなので、データーベースのバージョンアップはやる必要はなかった。これは後で書いてあるOmnibus GitLab packageのおかげだったのかな?

    ついでに同じくRubyで動いているRedmineのコンテナもバージョンアップしておく。こちらは一度プラグインを削除してから、一気に最新版にバージョンをあげる。こちらもコンテナのイメージのバージョンを最新版にして、今のコンテナを削除してから起動する。問題無く最新バージョンにアップデートしてくれた。

    以上で、鬼門であるRubyで動いているサイトのバージョンアップが完了した。何かトラブルがあるとRubyのシステムはお手上げ。

    そう言えばGilabでデーターベースはPostgreSQLだけど、同じQNAPのPostgreSQLを接続しに行かないなと思ったら、Gitlabのコンテナの中でPostgreSQLも含んで動かしているのね。それがOmnibus GitLab packageだそうだ。初めって知った。もっとドキュメントを読めや。> 自分

    SambaをLinuxサーバーのインストールしてファイルサーバーとして動かすよりも、サクッとQNAPを入れてしまったほうが簡単、安心、便利でおすすめ。ファイルサーバーだけではなくてIntelのCPUのQNAPなら、Dockerでいろいろとコンテナを設定してサーバーをたくさん立てられるしね。

    追記(2020年7月26日)

    RedmineとGitlabのリポジトリの連携をした。やることは以前の記事と同じだけど、最初はうまくできなかった。

    以上を設定してRedmineのプロジェクトのリポジトリタブにアクセスすると、505インターナルエラーが出てしまって困ったけど、これって裏で一生懸命にリポジトリの処理しているから時間がかかっているだけだった。しばらくすると、正常にリポジトリの表示ができた。

    あと、今までのGitlabでクローンするときはHTTPSでアクセスすると、何かライブラリのトラブルで認証のエラーをしていたけど、これがなくなっていた。これはバージョンアップしておいてよかった一つ。