Halcyon Days

海のように穏やかに生きたい

Laravelアプリケーションを常時SSL化する

環境

Windows11

Laravel8

Apache2.4

やりたいこと

Apache上にデプロイしたLaravelアプリケーションにHTTPSでアクセスしたいのでその対応をしたい。

環境設定

config\app.phpenv を編集する

環境にあわせて下記のように変更します。

'env' => env('APP_ENV', 'production') // 開発環境は'local'にする

AppServiceProvider を編集する

接続が環境にあわせて変更するように if を使って制御します。

<?php
 
namespace App\Providers;
 
use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\URL; // 追記

class AppServiceProvider extends ServiceProvider
{
    // 他のコード

    public function boot()
    {
        // ここから追記
        if (config('app.env') === 'production') {
            URL::forceScheme('https');
        }
        // ここまで追記
    }
}

config\app.php で編集した環境に応じて、HTTP接続かHTTPS接続かが決定されるようになりました。

参考サイト・資料

【MySQL】「ERROR 1372 (HY000): Password hash should be a 41-digit hexadecimal number」エラーの対処法

rootユーザーのパスワードを変更しようとしたときに発生した「ERROR 1372 (HY000): Password hash should be a 41-digit hexadecimal number」というエラーを解決する。

簡単に言うと「パスワードは41桁の16進数にしてね~」というエラー。

Agenda

  • 結論
  • どのようなエラーか?
  • 発生原因

結論

下記コマンドを叩けば解決する。

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('New_Password');

stackoverflowで同じ問題に悩んでいた人がいたので参考にしました。

MySQL Errors - You must SET PASSWORD/Password hash should be a 41-digit hexadecimal number

ドキュメント

MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.7.1.10 SET PASSWORD ステートメント

はじめに下記のようなコマンドを叩いていました。

SET PASSWORD FOR root@localhost = 'New_Password';
// ERROR 1372 (HY000): Password hash should be a 41-digit hexadecimal number

参考記事

dev.mysql.com

stackoverflow.com

Dockerコンテナ上にFlask API用のサーバーを立てる

やりたいこと

Flaskで作成したAPIにLaravelアプリケーションからアクセスしたい。

そのためにDockerコンテナ上にFlask API用のサーバーを立てる。

イメージ

最終的にはApacheでデプロイしたLaravelアプリケーションからDockerコンテナ上のAPIにアクセスするようにしたい。

手順

こちらの記事を参考にして構築した。

【Docker × Flask】コンテナでFlask製のREST APIを実装する~基本~ | SCRAWLED TECH BLOG

project-root:.
├─api
│  ├─test
│  ├─__init__.py
│  ├─api.py
│  ├─wsgi.py
│  └─__pycache__
├─log
├─Dockerfile
├─docker-compose.yml
├─requirements.txt
└─__pycache__

Dockerコンテナを作成するためのファイルを作成する

下記のファイルを作成する。

Dockerfile

FROM python:3.12

WORKDIR /code

COPY requirements.txt /code

RUN pip install --upgrade pip && \\

pip install -r requirements.txt

docker-compose.yml

version: "3"

services:
  api:
    container_name: "api"
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "5000:5000"
    volumes:
      - .:/code
    env_file:
      - .env
    tty: true

requirements.txt

Flask==3.0.0

インストールしたいパッケージを書く。

コンテナを作成する

下記のコマンドを叩く。

$ docker compose up -d --build

APIを作成する

コンテナを作成できたのでAPIを作成する。

記事を参考に作成させていただいた。

init.py

# Blank

wsgi.py

from api.api import api

if __name__ == "__main__":

    api.run()

api.py

from flask import Flask, jsonify, request

api = Flask(__name__)
@api.route('/')

def hello_world():
    return 'Hello, World!'

Flaskのサーバーを起動する

下記のコマンドを叩いてサーバーを起動させる。

$ flask run --host=0.0.0.0

 * Serving Flask app 'api.wsgi'
 * Debug mode: on
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on all addresses (0.0.0.0)
 * Running on <http://127.0.0.1:5000>
 * Running on <http://172.29.0.2:5000>
Press CTRL+C to quit
 * Restarting with stat
 * Debugger is active!
 * Debugger PIN: 625-009-671

動作確認

http://127.0.0.01:5000 にアクセスするとAPIが実行されていることがわかる。

参照ドキュメント

scrawledtechblog.com

理解してコードが書けるようになりたい

以前運営していたWordPress

 

ブログのタイトルが表題でした。

 

そんな話を書こうと思います。

 

書いているコード、使っている技術を理解しているか?

エンジニアになって現場で働き始めて半年以上が経ちました。

 

徐々に任せられる仕事も増え、やりたいことも見たかったから、非常に充実したキャリアを歩み始めた、と思っています。

 

しかし、ずっと自分の頭の中にはある不安があるのです。

 

それが、

 

「コードや技術の理解ちゃんとできてる?」

 

ってことです。

 

要は、今書いているコードや使っている言語・技術、CSなどなどをわかった上で使えているかということです。

 

先日、Dockerのログに関する記事を書きました。

 

この問題も、自分のDockerに関する理解のなさが招いたことなんですよね。

 

わからないから調べて、人の書いたコードを見てわかった気になって使っている。

 

時にはAIにコードを書いてもらったりしてわかった気になって使っている。

 

こんなことを続けていた時に、起きたのがDockerの問題でした。

 

このことは自分にある示唆を与えてくれた出来事だと思います。

 

「あ、自分の感覚は正しいんだ」、と。

 

スピードに争う勇気を持つ

牛尾さんの著者『世界一流エンジニアの思考法』に自分と同じようなエピソードが描かれています。

 

どんな話かをざっくりまとめると、

 

コードを書くことが遅かった牛尾さんが、他のエンジニアにどうしてコードを早く書けるのかを尋ねてみました。  

その答えが、基本をしっかり理解することに努めていたから、というものだったという話です。

 

詳しくは著書を読んでください。

 

アメリカは日本とは異なり、エンジニアは皆CSを大学で学んでいます。

 

そもそも働き方だって、仕事に対する考え方だって違います(以前見たツイートに「仕事が定時に終わらないのは適性がないから」みたいなことが書いてあって驚きました)。

 

そもそもバックグラウンドが違うんですよね。

 

盤石な基礎がある状態でエンジニアをしているのか、自分のようにボロボロの基盤でエンジニアをしているのか。

 

このバックグラウンドの差は大きいと思っています。

 

また彼ら(牛尾さんの同僚たち)は、基礎の理解に多くの時間を費やすそうです。

 

技術理解のためにモックアップを作ったり、仕事を定時に終わらせて技術理解のための時間を作ったりしています。

 

とりあえず動けばいい、わからなくても使う自分とは大違いです。

 

そんな状態で作り出したプロダクトはハリボテみたいなものだと思います。

 

インシデント対応もできませんしね。

 

抱いた違和感や書籍などからの示唆を踏まえ、もう少しスピード争う勇気を待とうと思いました。

 

エンジニアになってたかが半年くらい、CSのバックグラウンドもない、言うなれば「なんちゃってエンジニア」でしかない自分は、多分このまま同じようにやっていてもずっとなんちゃってなんだろうなって思ったからです。危機感でした。

 

だから、手を広げることをやめて、今使っていない言語や技術、そしてCSについて理解するようにしようと思いました。

 

1年しっかり下積みをします。

 

PHP Conf小田原の記事でも触れたように、これからSREに進むと決めたので、それに関連する技術と背景を1つずつ学んでいきます。

 

途方もなく、加えてスピードも早いIT業界ですが、根無草にならないために地盤を固めます。

 

たぶん、活躍できるかどうかの別れ道って今なんだろうなって思うので。

 

地道に1つずつ学んでいきます。

 

後から見て、こう思ってたから今があると思えるといいな。

 

頑張ろう〜〜〜👊🏻👊🏻👊🏻

 

 

 

docker-composeのビルド中のログを出力したい

なぜやろうと思ったか

仕事で必要な技術理解のために簡単なモックアップを作ろうと思い、DockerでPHP・Nginx・SQL Serverのコンテナを作成しようとした時のこと。

何回 docker-composeをしても、 sqlsrvpdo_sqlsrvphp.iniに追加されずハマっていました(お恥ずかしいことに2日費やしました)。

Dockerfileはそれらが正しくインストールされるように構成していて、ちゃんとビルドも行われる(途中で止まらない)のにも関わらず、どうしてもphp.iniへの書き込みだけが上手くいきませんでした。

ふと、「 docker compose build実行中のログを見ればわかるかもしれない」と思い、ログを表示させてデバッグすることにしました。

その時の備忘録です。

この記事でわかること

  • docker compose build 実行中のログを表示させる方法

Dockerfileの内容には触れません。

やったこと

下記のコマンドを叩いてログを表示させました。

docker compose build --no-cache --progress plain

原因は php.ini の場所が見つけられなくて書き込めていなかったそうな……。

通常のビルドはログがどんどん流れていってしまうので気づきにくいですね……。

インストール時のエラーであれば、処理がストップするのでわかるのですが、今回は最後まで通ってしまうので把握に時間がかかりました。

ログってやっぱり大事ですね。

エラーが出た時はしっかり読むように心がけていましたが、今回のようにエラーを吐き出さない場合にどうするかを考えるきっかけになりました。

今後はログを何かしらに出力して、エラーをモニタリングするような仕組みを考えたいと痛感します。

まだまだやるぞ〜〜👊🏻

参考記事

下記の記事を参考にしました!
ありがとうございました!
docker compose build実行中のログを詳細に出す方法
【Docker】build時に詳細なログを出力する
Dockerfileをbuild時にログを出して楽にデバッグしよう!

AWS Cloud Practitionerを取得したので勉強と反省点まとめ

先日AWS Cloud Practitionerを取得しました。

 

748点とめちゃくちゃ低い点数での合格だったのですが、まぁ受かったんで許してください。

 

正直、受かると思っていなかったので試験終わって「合格」の文字が出た時は思わずガッツポーズしました。

 

よかったよかった。

 

さて、前置きはここまでにして、合格までに何をしたか、何がいけなかったかなどをまとめておこうと思います。

 

やったこと

やったことは以下の通りです。

学習期間はだいたい2週間くらいでした。毎日の通勤の時間(往復2時間)と寝る前1時間くらいの勉強でした。休日は3時間くらい?

 

まずはSkill Builderと教科書で知識を頭に入れ、問題集をひたすら解く、という王道の方法でした。

 

どうしても覚えられないものだけAnkiに入れて復習していました。

 

最後の方は覚えることができたのですが、もっと効率的にできたよなぁと思います。

 

反省点

では、ここから反省点です。

 

多くの人がやっていた「Udemyの問題集を解いて答えを読む」が合わなかった

問題集を解いた人はわかるかもしれませんが、解答を見られるのは全部解き終えてからです。

それが本当に合いませんでした。

問題文を再度読む必要があるし、どうしてこの選択肢を選んだかを思い出さなければならないからです。

ITパスポートや基本情報なのでよく使われる「過去問道場」のようなすぐ答えが見られるような形式の方が自分にはあっているなと思いました。

 

Ankiの作成に時間をかけすぎた

「解く→答えを見る」というフローを作りたかったのでAnkiを使うことにしました。

しかし、Ankiの作成って案外時間がかかるのです。

土日の貴重な時間を作成に費やしてしまったのは本当に失敗でした。

「作成して満足」みたいな感じにもなっていましたから。

Ankiは回してからが本当のスタートです。

 

電車の中は意外と集中力が削がれる

騒音や他人の会話、通過駅への意識など、様々な要因で集中力が削がれました。

Ankiのようなフラッシュカードを回したり、動画見たりするにはいいかもしれませんが、問題を解くみたいな集中力が必要なタスクには不向きですね。

 

改善点

次はDeveloperを受験します(AssociateコンプリートとDevOps取得が目標)。

 

正直、もっと効率よく合格できると思います。

そのためには今回の反省を活かさねば〜と思ったのでやり方を変えてみました。

 

Udemyを一問一答みたいにした

「天才かよ」ってやり方をしていた方がいたので真似させていただきました(記事が削除されてしまったっぽい)。

 

やり方は簡単。

 

アプリとウインドウでUdemyを2つ開きます。

ひとつは問題を、もうひとつは答えを開きます。

解答したら答えを見る。

 

それだけです。

このやり方を知った時は「なぜ思いつかなかったんだ……」と感じました。

 

この方法のいいところは、反省点をカバーできる以外に、これから解く問題でアウトプットができるということ。

 

例えば、1問目の解答で読んだ知識を10問目の解答に活かせるみたいな感じです。

 

問題集の中でインプットとアウトプットができるようになるのがいいなと思いました。

 

UdemyじゃなくてTechStockでもいいなと思った

TechStockというWeb問題集を使うと、わざわざUdemyを2つ開くという力技( )をしなくてもよくなります。

 

https://cloud-license.com/

 

90日間で4500円くらいの料金で様々な認定試験問題の解くことができます。

 

Udemyで試験ごとに2000円で問題集を買うより、こちらの方がお得だと思います。

 

90日間という縛りはありますが、3ヶ月で必要なものだけとって仕舞えばいいのですから。

 

以上、もっと効率的にやれたなってお話でした。

 

次回も頑張ろう〜〜〜。

はじめて参加したカンファレンスは新しい領域との出会いの場だった

こんにちはしょまです。

 

2024年4月13日に開催されたPHPカンファレンス小田原に参加してきました〜!

 

phpcon-odawara.jp

 

初カンファレンス参加ということもありどきどきでした。

そもそもPHP歴もエンジニア歴も短かったので、行ってもためになることがあるのかとめちゃくちゃ不安だったからです。

 

知識もないから行っても楽しいのだろうか、と。

 

参加されるのは社会の前線で活躍されている方々ばかりだから、ひよっこの自分がばかにされるんじゃないか、と。

 

こんな感情を抱えながら参加しました。

 

参加しなきゃわからないことばかり!!

f:id:Hal40n:20240414162322j:image

 

結論、参加してよかったです!!!

 

めーちゃくちゃ良かった!

 

エンジニアとして活動していくモチベーション上がったし、CSもっと勉強しようと音持ったし、次はLTやりたいし、もういろんなことを思いました。

 

もっと頑張ろうって思えたことが一番良かったです。

 

最近、少しモチベーションが下がり気味(どの道に進むか迷子になっていたから)だったので、そのモチベーションが再び上がり気味になりました。

 

特にSRE分野との出会いが大きかったです。

 

SREとの出会い

私が所属している部は親切の部で、全く制度が整っていません。

コーディングや運用規約、システムの利用基準など、様々なものが決められていない状態です。

 

まだ入って間もないですが、僕自身、そのような状態がとても気持ち悪いと思ってしまうので、どうにかしてやろうと考えていました。

 

もっと開発や運用がしやすい環境にできれば、自分もメンバーも楽しく開発できるのではないかと。

 

そのような思いを抱えている中で、Shotaさん横山さんのSREに関するセッションを拝聴して、

 

「あ、自分のやりたいことってこれだ」

 

とほぼ直感で思いました。

 

深い霧がぱっと晴れた、そんな感じでした。

 

Shotaさんのセッションで運用の具体例を知ってワクワクして、その後の横山さんのセッションで類型を知ってもっと調べたいと思ったので、

 

この順番にしてくれた運営の皆さんは神か? と思ってます。

 

本当にありがとうございます……。

 

少しずつSREについて調べて、社内で実施していきたいと思っています。

まずは一歩前進した気がします。

 

Shotaさんのプレゼン資料

PHPカンファレンス小田原2024 - Speaker Deck

 

横山さんのプレゼン資料

SREとその組織類型 - Speaker Deck

 

素敵なカンファレンスありがとうございました!

企画してくれたあすみさん、

そして運営をしてくださった皆様、

他の参加者の皆様

本当にありがとうございました!!

 

めちゃくちゃいい1日でした!!

 

もっと知識をつけて、

エンジニアの友達作って一緒に参加したら

 

もっと楽しいだろうなと思ったので、

 

来年は誰か一緒にいきましょう。

ぜひ。

 

楽しかった〜〜!!!

 

余談

久々に海見て、花見もしてきた。

f:id:Hal40n:20240414162352j:image

f:id:Hal40n:20240414162418j:image