こぼれネット

今回、部署異動となり、新しい部長との面談を行うために、自己紹介用に自分がこれまで関わってきた業務を年表風(図入り)に記載したものの、レビューと修正を行っていました。

From this period, I have transferred to a new research section. So I have reviewed and modified my carrier history sheet with illustrations in order to prepare for the meeting with my new boss.

感想は、

While reviewing and modifying it, I was self-satisfied that

(1)よくもまあ、これだけ、異った沢山の研究業務をやってきたものだ

(1)How much I had done a lot of research.

と、いう、ある種の自己満足と、

and at the same time, I faced the reality of

(2)これだけ色々やってきて、何一つ、世界にインパクトを与えた研究がないなぁ

(2)There is no research that had given something impact to the world.

という現実を直視して、何とも言えない気持になっています。

I feel something I cannot make words.

-----

私は、『どこでも喰っていけるだけの技術力』に拘って生きてきました。

私にとっての通貨は、―― 「技術力」ですね。

I have stuck to get the technical skills to survive in the research life.

しかし、それは同時に『どの分野の技術にも拘泥しない軽さ』も生み出したのだと思います。

However, that has generated "light footwork" I didn't obsess with any field of technology.

『自分ができる領域を守ること』に偏狭して拘泥するセクショナリズムは、確かに見苦しい。

It is true that sectionalism with narrow-minded and obsession to protect what I can is ugly.

しかし、自分ができる領域を守ることに淡白な人間に、ブレークスルーは降りてこない。

However, any break-through doesn't come to a person who is not interested to keep their own field

どちらを選ぶかは、あなたの自由ですが、『どこでも喰っていけるだけの技術力を育成せず』、かつ、『自分の領域を守るための闘争もしない』というのは、ちょっとヤバいかもしれません。

Which one you choose depends on you, however, "not developing the technical skill to survive" and "not fighting to protect your domain" may be risks for you.

-----

私は、『手の抜いて生きてきた時間はない』と自信をもって言えますが、それで『何かを成せるか』は無関係です。

I can confidentially say that I have not spent any time making myself easy. However, it seems not related to "what I could do something great"

結局のところ、

In short,

■自分のプログラムが動いた瞬間が、とても嬉しい

"I am happy to watch my program to work well"

■連載コラムを脱稿した時に飲むノンアルビールが一番美味しい

"I love drinking non-alcoholic beer just after finishing writing columns"

という程度の人間には、『世界にインパクトを与える』というフィールドには関われないのだ、と思います。

I think that for a person like me, I cannot access the research field about the world's impact.

まあ、私は、それでいいです。

Well, it is O.K. for me.

> uvicorn main:app --reload

main.py

import uvicorn
from fastapi import FastAPI, File, UploadFile

import shutil
import os

app = FastAPI()

@app.post("/files/")
async def file(file: bytes = File(...)):
    content = file.decode('utf-8')
    formatfile = content.split('\n')
    return {'filedetail': formatfile}

@app.post("/uploadfile/")
async def upload_file(file: UploadFile = File(...)):
    if file:
        filename = file.filename
        fileobj = file.file
        #UPLOAD_DIR = os.getcwd() 
        #print(UPLOAD_DIR)
        #upload_dir = open(os.path.join(UPLOAD_DIR, filename),'wb+')
        upload_dir = open(os.path.join("C:\\Users\\ebata\\fastapi6\\", filename),'wb+')
        shutil.copyfileobj(fileobj, upload_dir)
        upload_dir.close()
        return {"アップロードファイル名": filename}
    return {"Error": "アップロードファイルが見つかりません。"}



'''
@app.post("/uploadfile/")
async def upload_file(file: UploadFile = File(...)):
    return {'filename': file.filename}
'''

クライアントは、こうなる。

前提は、C:\Users\ebata に dummy.txtがあること。
そして上記のmain.pyは、C:\Users\ebata\fastapi6にあること(まあ、そのへんは適当に変えて使って下さい)

C:\Users\ebata>curl -X POST http://127.0.0.1:8000/uploadfile/ -H 'accept: application/json' -H 'Content-Type: multipart/form-data' -F file=@dummy.txt;type=text/plain

クライアントプログラムは作成中

ありふれているけど、いつの時でも頭を抱える状況に、今回も頭を抱えています。

It's common, however, it has made me annoyed, and I am annoyed now.

今回は、chkdskでも、復旧できませんでした。

This time, "chkdsk" didn't save me.

「chkdsk f: /f」という掛け軸が販売されるのであれば、今、直ぐにでも購入する準備があります。

各種の市販ツールも試してみたのですが、ダメでした。

I tried various commercial tools, but they were in vain.

https://teratail.com/questions/8xzab7sat8gujj#reply-3jfh5txotuqxqb

の質問サイトに投げたものですが、ローカルでも作っておきます。

実現したいこと

TLS対応にしているGo言語のサーバを、Dockerコンテナの中から使えるようにしたい

前提

GO言語を使ってサーバを作っています。これらのサーバをDockerコンテナに格納して、運用しやすくしたいと考えております。

発生している問題・エラーメッセージ

Dockerコンテナに格納すると、https(×http)通信が使えません。

cert.pem、key.pemを使わない場合、http://127.0.0.1:18888で、ブラウザに"hello"メッセージがされますが、cert.pem、key.pemを使ってhttps://127.0.0.1:18888とした場合、「このサイトにアクセスできません」と表示されます。

該当のソースコード

package main

import (
	"flag"
	"fmt"
	"log"
	"net/http"
	"net/http/httputil"
	"os"
)

var url_host string

func handler(w http.ResponseWriter, r *http.Request) {
	dump, err := httputil.DumpRequest(r, true)
	if err != nil {
		http.Error(w, fmt.Sprint(err), http.StatusInternalServerError)
		return
	}
	fmt.Println(string(dump))
	fmt.Fprintf(w, "<html><body>hello</body></html>\n")
}

var addr = flag.String("addr", "127.0.0.1:18888", "http service address") // テスト

func main() {
	http.HandleFunc("/", handler)
	fmt.Println("url_host:", url_host)

	log.Println("start http listening :18888")

	var httpErr error
	if _, err := os.Stat("./cert.pem"); err == nil {
		if httpErr = http.ListenAndServeTLS(*addr, "./cert.pem", "./key.pem", nil); httpErr != nil {
			log.Fatal("No pem file with https error: ", httpErr.Error())
		}
	}
}

#FROM golang:apline
FROM golang:1.16.3-alpine
WORKDIR /go
ADD . /go
CMD ["go", "run", "main.go"]

docker-compose.yml

version: '3'
services:
  app:
    build: .
    ports:
      - "18888:18888" # "ホストのポート:コンテナのポート"

試したこと

上記のmain.go のfunc main()を以下のようにしている場合は,http(×https)で通信できます。

func main() {
    var httpServer http.Server
    http.HandleFunc("/", handler)
    log.Println("start http listening :18888")
    httpServer.Addr = ":18888"
    log.Println(httpServer.ListenAndServe())
}

補足情報（FW/ツールのバージョンなど）

■Windows10上のDocker for Windowsを使用しています。
■Dockerコンテナを使わないで、 windowsのコマンドプロンプトから起動する場合は、"https://127.0.0.1:18888"は問題なく起動します。

で、頂いたご回答が以下の通り。

Dockerfile

#FROM golang:apline
FROM golang:1.16.3-alpine
WORKDIR /app
ADD . /app
CMD ["go", "run", "main.go", "-addr", ":18888"]

と最後の一行を、CMD ["go", "run", "main.go", "-addr", ":18888"]

とするだけでした。

で、以外な盲点が、

ブラウザのキャッシュを消去しないと、変更がブラウザに反映されない

だったりします。(何度も経験しているのに、これをよく忘れるんだよなぁ)

感想

散々、色々試したあげく、最初に頂いた、Dockerfileの内容に変更することで、無事問題を解決することができました。現在、Dockerの中で立ち上げたgoのサーバに対して、https://localhost:18888で表示されることを確認しました。

今後のサーバ立ち上げに関して、かなり有益な知見となりました(実サーバ運用では、ご指摘の内容を反映してリスクを回避したいと思います)。 この度は、誠にありがとうございました。

以上

本日、リモート環境で打ち合わせをしている最中に、比較的大きめの地震が発生しました。

During a remote meeting, a relatively big earthquake occurred.

が、打ち合わせはそのまま問題なく進んでいるので、『いちいち地震を気にしないで会議を進めるのだ』と思っていました。

However, the meeting continued without any trouble, I thought "They don't care about earthquakes"

ところが、3秒くらい経過したところで、「あ、揺れている」「比較的大きいですね」という声がチラホラ聞こえてきました。

After about three seconds, the voice "Oh, it's shaking," or "It's relatively big" were coming, so I thought

―― 生れてはじめて、地震波の存在をリアルに実感した

"For the first time in my life, I really felt the existence of earthquake waves"

と思いました。

"巨大地震の発生直後、飛行場の管制官が、離陸の最中にあった旅客機に停止指示を出さずに、空に逃がすシーン"

-----

ただ、Twitterで震源地情報などを調べると、どうも、違和感がある。

However, I felt a sense of discomfort, when I looked up the epicenter on Twitter.

私の住んでいるところが、一番震源地より遠いはずです。

My location must be far from the epicenter, I thought.

私の考えた、仮説の一つは、『他の人の(高価な)家は免震構造が頑強であるが、私の(高価でない)家は敏感にP波(初期微動)を感じられる』です。

One of my hypotheses is that "other member's houses are expensive and robust seismic isolation structures, but my house is not expensive and can feel P-waves (initial microtremors) sensitively.

あまり愉快な仮説ではありませんが。

Anyway, it is not a very pleasant hypothesis.

なんでこれが

こうなる？

わからん・・・

私は、自分のWebサイトをDB化しています ―― GoogleエンジンとWordPressの検索機能を使っているだけですが。

I use my website as DataBase, using just the Google search engine and search functions of WordPress.

これ結構便利です。

This is really useful.

「○○についてネタが欲しい」と思った時に、すぐに探し出せるからです。

Whenever I want to tell a story about a specified theme, I can find it soon.

Amazon 恐るべし。

-----

今日も会社で、あるテーマについて投稿しなければならなかったのですが、数秒でネタを見つけました。

Today I was ordered to submit a short story about a specific theme, and I could find it in a few seconds.

まあ、ネタの使い回しもあるので、何度も同じ話を聞かされている人もいるでしょうが ―― まあ、そこは、諦めて下さい。

Well some people should hear my story again and again, I ask them to give up.

-----

なんだかんだ言って、私のWebの創立は、1993年です ―― 創業30年の老舗Webサイトです。

Anyway, my Web establishment was founded in 1993 -- a 30-year old Web site.

まあ、規模的には「和菓子屋」というよりは「駄菓子屋」ですが ――

Well, in terms of scale, it's more of a "candy store" than a "wagashi ya" -- however,

それでも歴史だけに着目すれば、AmazonやGoogleなどのGAFAなんぞは、小僧のようなものです。

Still, if you focus only on history, GAFAs like Amazon and Google are like little boys.

決して、負け惜しみではありません。

By no means is this a sore loser?

昨日書いたようなデッドロックに、本日、遭遇することになりました。

『システムの奴隷』

Today, I faced the "Dead Lock" I wrote yesterday.

だいたいヤバいことは、システムをいじった直後に発生するというのは「お約束」です。

Almost all of the troubles will happen just after the system modification. This is so typical.

-----

で、このデッドロック対策について、教えを乞い、100ページのマニュアルを送ってもらったのですが、「もうダメだ」と諦めました。

In order to avoid the deadlock, I asked workers in my company. A guy gave me a manual book with more than 100 pages. After reading it, I gave up easily.

しかし、その人から『簡単ですよ』と言われて、実際に試してみたら、ざっくり1分で設定が完了しました。

However, the guy gives a reply, "It was a piece of cake", I could complete the set in a minute

-----

ここから導かれる事実は2つ。

The facts lead to the following.

■マニュアルは、本当に欲しいことを、分からないように記載される傾向がある

- Manual books are apt to be written difficult, so too hard to get us what we want.

■人間(というか、私)は、マニュアルより、人間の言葉を信じる傾向にある

- A human being (like me) is apt to believe human words more than manuals.

ということです。

私も今回のメモを纏めましたが、「10行の文章 + 図面のハードコーピー2枚」になりました。

I made a memorandum about what I did, and the volumes are only 10 line-document and two hardcopy sheets.

-----

マニュアルがあんなに長く、分かりにくいのは、問題が発生した時に「問題」になるからです。

The reason why manuals are so long and hard to read is to become a problem if the problem happens.

一方、私のメモは私の為のものなので、他の人がそれを読んでシステムを壊すなどの被害が起ったところで ―― 私の、知ったことではありません。

On the other hand, my memorandum is just for me, so even if someone tries some actions by reading my memorandum, it is not my business.

私だって、他の人のメモで、色々酷い目にあったこともあります ―― これは『お互い様』です。

Even I also got in terrible trouble by reading another's memorandum. So It is "mutual"

まあ、普通の企業には、恐しくてとてもできないことだとは思いますが。

Well, I think it is something that ordinary companies are too afraid to do.

ITシステムが会社になかった時代 ―― いや、本当にそういう時代があったんです。

"The ear where there is No IT system in companies". --- I am not kidding.? The era had existed in the old days.

ほんの20年くらい前は、それが当たり前でした。

It was natural just before 20 years ago.

勤怠管理の提出を怠れば、総務部が怒りの声で電話をしてきて、遅延した伝票の処理は庶務担当の人に、頭を下げて、定期的にお土産を提供していれば、なんとかなりました。

If I failed to submit my time and attendance, a person in the general affair department called me in an angry voice. When I delayed vouchers to the accounting department,? I kept my head down and sometimes I give them souvenirs periodically.

事務処理は、"なあなあ"な人間関係で、なんとかこなすことができたのです。

The paperwork was managed through a casual relationship.

そういう意味では、インターフェースの優れた、いわゆる「ネアカ」「陽キャ」「恫喝」「土下座」というのは、社内において圧倒的に有利、というか、立派な「インタフェース」だったのです。

In that sense, the so-called "cheerfulness," "cherry," "frights," and "down on their knees", were superior interfaces to keep our paper management in my company.

-----

しかし、ITシステムは、そんなこと『気にしません』。

However, IT system doesn't take care of them at all.

決済日を70日経過しても、警告一つ寄越さず、期末の精算処理の時点で、社内が大騒ぎになります。

Even if the deadlines pass through over 70 days, the IT system doesn't put any alert message. As a result, on the day of the end of the fiscal year,? my company came to be in a fuss.

締切の時間を5分遅れたら、報告書を受理しません。

IT system rejects to get a report even if I delay submitting it by just five minutes.

それどころか、末日のシステム集中でシステムダウンをしても、それに対して謝罪も弁済も補償も猶予もなく、そのまま、手続を『不受理』とします。

On the contrary, even if the IT system is down for access concentrations, they have no apology, reimbursement, compensation, or grace, and just reject my submission.

そのため、以前は締切日に資料を提出するのは避けていました。 なぜなら、その日は「システムダウンの日」だと決めているからです。

Therefore I used to avoid submitting any materials on the deadline day. Because I decide the day is "The system down day".

つまるところ、AI技術などと関係なく、業務のIT化によって、私たちは、すでに

In short, regardless of AI technologies, with IT management by computer, we have already become

『システムの奴隷』

"Slavers of the IT system"

と、なっているのです。

-----

私の勤務している会社では、会社の業務システムに対して、年に数回のパスワード変更を実施しなければなりません。

My company orders us to change my "password" several times a year for the company work system.

それを実施しない場合の、システム側からの制裁は、単純で、そして残酷です。

When we don't do it, the sanctions from the systems are simple and brutal.

『全業務システムへのアクセス停止』です。

"All accesses to all work systems are suspended".

業務システムだけでなく、メール、チャット、IP電話、何もかもかもが使えなくなります。

Not only the work systems, but also e-mail, chat, IP phones, and everything else will be out of service.

-----

ところが、パスワードの変更をすると、そのパスワードの変更を他のシステムで承認するという面倒なシーケンスが働きます。

However, when I try to change my password, the change must be admitted by another system. This is a seriously complicated status.

この結果何が発生するかというと ―― デッドロックです。

As a result, what will happen? It is a "deadlock".

システムにアクセスするのに新しいパスワードが必要なのですが、そのパスワードを承認するシステムが、そのパスワードでなければログインできない、という状態になり ――

When I try to access a work system, I need to use the new password. However, the system also needs the new password.

つまるところ、『パスワード変更をすることで、どのシステムにもアクセスできなくなる』という状態が発生するのです。

In short, the situation of "changing password makes me not access any work system" occurs.

デッドロックを発生させない為に、あるシステムにパスワード変更の効果が及ぶ前に処理をしなければならないなど、クソ面倒くさい気遣いが必要になっています。

In order to avoid the deadlock, I have to start the system before being spread the changing password to the system. Anyway, it is an annoying process I have to.

こうなると、もはや、単なる奴隷ではなく、

In a sense, I am not just a slave but,

『システムの下僕』

"Servant of the System"

といっても過言ではないでしょう。

現代の私たちは、望む望まずに関わらず、マイクロソフト社の「Windows OS」と「Office」の奴隷・・・もとい、ユーザとなっています。

I believe that it would not be an exaggeration.

腹立たしいことこの上もありませんが、「ネアカ」「陽キャ」「恫喝」「土下座」を排除した世界の一つの形であるのは事実です。

It is beyond infuriating, but it is true that this is one of the worlds that eliminate "cheerfulness," "cherry," "frights," and "down on their knees".

ただ、システムデッドロックに陥った場合、そこから抜け出すのは、簡単ではない世界です。

Still, it is also very difficult to escape from the world when we are caught by the system deadlock.

-----

次のAI技術の目指すものは、「ネアカ」「陽キャ」「恫喝」「土下座」などのアナログインターフェースを、正しく理解するものなのかもしれません。

The next-generation AI technology might be something to understand the interfaces of "cheerfulness," "cherry," "frights," and "down on their knees".

もっとも、そのAI技術では、コンピュータが『うるせい！大声出すな！！』と応答してくるかもしれませんが。

However, with the AI technology, a computer might respond with "Shut up! Stop yelling!!" against your loud claims.

cert.pem やら key.pem に、localhost や 127.0.0.1を含めて作っていなかったから。以上

C:\Users\ebata\kitaya>curl https://localhost:8080
curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - 失効の関数は証明書の失効を確認できませんでした。

cert.pem = fullchain.pem  key.pem = privkey.pem ということで良いのだろう

ローカルネットワークにおける「オレオレ証明書」の作り方 "http: TLS handshake error from 192.168.0.22:59914: remote error: tls: unknown certificate"のエラーを、ようやく消せました