동기화 / etl / elt / extract transform load
database의 변동내역을 다른 곳(대체로 DB)에 반영해 준다.
ref.1 의 내용을 정리했다.
su user1으로 들어가서 image를 다시
build하면 error 가 난다.Error: error creating tmpdir: mkdir /run/user/1000: permission denied/etc/resolv.conf재부팅되면, podman 은 refreshing the state 를 해야한다.
다음의 동작을 ‘refreshing the state’ 라고 부른다.
필요한 이유:
tmpfs filesystem 에서 보초병
파일(sentinel file)을 만들어 사용하기로 정했다./tmp 이다. 하지만 /tmp가 항상
tmpfs filesystem 이 라는 법은 없다./run을 이용한다. 이곳은
tmpfs 라는 것이 보장된다./run은 root 에 의해서만 write 이 가능하다./run/user/$uid 이다. (/run/user/$uid 에 대한
이야기는 ref.2
를 참고)pam_systemd에서 만든다.)/tmp를 사용하게 된다./tmp 가 tmpfs 가 아닐 가능성은 있지만, 더
나은 방법이 없다.run/user/$uid가 사라지고, 이것은 Podman 이
refresh the state 를 하고, 현재 running 하고 있는 container들이 running
하지 않다고 표시하게 된다.login enable-linger)login enable-linger 은 long-running container들을
실행하는 user들은 모두 이 것을 이용해야 한다.su, sudosu, sudo는 login session 을 만들지 않는다.
그래서 /run/user/$uid 를 만들지 않는다.su,
sudo로 사용하면 안된다. Root container들은 문제가
없다.loginctl enable-linger 를 사용해서 그 user에
대해서 영구적인 user session 을 만들면 가능하다.sudo, su 대신에 user session 을
만들어주는, machinectl login 또는 ssh 를
사용해서 접근하면 된다.su
와 sudo 를 사용해서 rootless podman 을 실행하는 법sudo 또는 su로 Podman 을
실행하면, /tmp가 temporary files directory로 잡혀서
실행가능--runroot flag 를 이용해서 temporary files directory
path 를 지정해서 사용할 수 있다.--login argument가 필요할 것이다.팟맨 / 포드맨 / 파드맨/ 왜 안보이나, / 왜 컨테이너가 안보이지 /
update 2023-08-02: 자세한 내용은 rootless Podman 를 ‘sudo’, ‘su’ 로 사용하면 안되는 이유 를 보자
podman 에서는 해당 계정에서 만든 container들은 해당 계정으로만 볼 수
있다. 그래서 당연히 실행도 해당계정으로만 해야 한다. 그래서 만약 user1
로 만든 container는 다른 계정에서 sudo 등을 이용해서 실행할
수 없다.
그리고, root 도 non-root user가 실행한 container를 볼 수 없다.(ref. 1)
ref. 3 을 보면, 자세한 설명이 나온다. 여기서 간략하게 추려보면
/run/user/$UID 를 이용한다. 만약 이 directory 를 사용할 수
없다면, /tmp를 이용하게 된다. 그런데 이 결정은 podman 이
처음 run 할때 정해지고는 변경되지 않는다.su나 sudo를 이용하면 login session
이 만들어지지 않는다. 그래서 /run/user/$UID 가 없다./run/user/$UID
대신에 /run을 사용하기 때문에.su나 sudo를 이용해서 rootless
container를 실행하는 것은 권장하지 않는다./tmp를 실행하도록 만들기도 한다.
그러나 이것도 문제는 있다. 이부분은 ref. 3 을 확인하자.
rpc /
.proto file 로 구현된다.이 .proto file을 protoc를 이용해서 compile 한다. 그러면 target platform 에 대한 client code 와 service code를 만들어 준다. code는 다음 내용을 가지고 있다.
browser client 를 위한 gRPC의 javascript 구현이 gRPC-Web 이다. gRPC-web client 들은 gRPC service들에 접근할 때 Envoy(proxy)를 이용해서 연결하게 된다
envoy 가 필요한 이유:
envoy proxy server가 web browser에서 보내는 gRPC 요청을 받아서 gRPC server로 넘겨준다.
http 에서 server쪽에서 client 쪽에 update 를 하려면?
이것은 기본적으로 불가능하다. 단순하게 생각하면, server 가 request 를 보낸다고 하면, 그것을 받아줄 server가 존재해야 한다. 그럼 어떻게 할까?
예전에는 이것을 위해서 계속 client 에서 물어보는 방법을 택했다.
그런데 이제 browser에서 SSE 라는 것을 지원하기 시작했다.(2009년 4월)
connection 을 맺을 때는 http header에 특정 field를 넣어줘야 한다. 그러면 browser에서 이 header를 보고 WebSocket protocol 로 전환한다. 그리고 나서 browser가 서버쪽에 Sec-WebSocket-Key에 random하게 만든 key를 base64-encoding 해서 보내게 된다. 그러면 서버는 응답에 Sec-WebSocket-Accept 를 보내준다. 그리고 이후로 data를 WebSocket protocol 을 이용해서 주고받게 된다.(아래 그림 참고)
client --> server
--------------->
Sec-WebSocket-Version: 13\r\n
Sec-WebSocket-Key: lXp6HCmTm4HP8Roz/CmoOA==\r\n
Connection: Upgrade\r\n
Upgrade: websocket\r\n
Host: localhost:8080\r\n
client <-- server
<----------------
Upgrade: websocket\r\n
Connection: Upgrade\r\n
Sec-WebSocket-Accept: K/PoUF1zivlox8EW6nXD9C9qYDM=\r\n
웹소켓 / 간단 예제 /예시 /example / web socket /
npm init
...
npm run ws-s
npm run ws-c
생성형 ai / 구별 / 어렵다
OpenAI가 사람의 글쓰기와 AI 생성 텍스트를 구별하는 것을 목표로 한 도구의 정확도가 낮아서 종료하기로 결정 업데이트된 블로그 글 내용에서, OpenAI는 7월 20일을 기준으로 이 AI 판별기(classifier)를 중단하기로 했다고 밝혔습니다. “우리는 피드백을 반영해 현재 더 효과적인 텍스트 출처 기술에 대해 연구 중입니다.”라고 회사 측은 말했습니다.