열심히 살자

외국 상품을 파는 가게 사장님의 홈페이지를 이전하는 과정에서 상품을 등록하는 과정을 외주로 받게 됐다.

현재 상품명은 {영어 / 제2외국어 [무게(kg/g)]} 혹은 {제2외국어 / 영어 [무게(kg/g)]}로 설정되어 있었다. (연속된 띄어쓰기는 0개 이상)

처음에는 제2외국어를 제거하려고 했지만 영어와 숫자가 아닌 것을 제거하는 것이 더 편하다는 것을 깨달았다.

아래는 현재 상품명이 저장된 name.xlsx 파일에서 상품명을 꺼내 정규표현식으로 {영어 [무게(kg/g)]}로 바꾼 후 rename.xlsx 파일에 저장하는 코드이다.

import openpyxl
import re


wb = openpyxl.load_workbook('name.xlsx')
sheet=wb.active
cells = sheet['A1':'A46']

list_var = []

for row in cells:
    for cell in row:
        list_var.append(cell.value)

for i in range(0, 20):
    tmp = re.sub('[^0-9a-zA-Z]+', ' ', list_var[i]) # 이러면 .도 지워지는데, 사용하는 홈페이지에 이미지 등록할 때 파일 명에 .이 들어가면 안되서 .도 삭제해야 했음
    list_var[i] = tmp

# 첫 번째가 공백이면 제거
for i in range(0, 46):
    list_var[i] = list_var[i].strip()

for i in range(0, 46):
    sheet.cell(row=i+1, column=1).value = list_var[i]

wb.save('rename.xlsx')

cells의 크기에 맞춰 반복문을 내가 수정해줘야 한다는 단점은 나중에 고치기로 한다.

도커는 LXC(Linux Container) 기술을 기반으로 만들어졌다. (Docker 1.8 이전 버전까지 사용)

LXC

Host OS에서 프로세스 간 벽을 만드는 기술이다.

LXC에 포함되는 기술들 :

• 커널 네임스페이스 (ipc, uts, 마운트, pid, 네트워크, 사용자)

• Apparmor와 SELinux 프로파일

• Seccomp 정책

• Chroots (pivot_root 사용)

• 커널 캐퍼빌리티

• CGroups (Control Groups)

LXC 컨네이너는 보통 chroot와 실제 가상머신의 중간적인 성격을 갖고 있다고 생각되어 진다. LXC의 목적은 별도의 독립적인 커널이 없어도 보통의 리눅스 설치에 가까운 환경을 만드는 것이다.

CGroups

프로세스들의 자원의 사용(CPU, 메모리, 디스크 입출력, 네트워크 등)을 제한하고 격리시키는 리눅스 커널 기능

Kernel namespace

리눅스의 namespace 기술은 하나의 시스템에서 수행되지만 각각 별개의 독립된 공간인 것처럼 격리된 환경을 제공하는 lightweight 가상화 기술이다.

종류:

    Mount

    Process ID (PID)

    Network

    Interprocess Communication (IPC)

    UTS

    User ID (UID)

Reference

LXC : https://linuxcontainers.org/ko/lxc/introduction/#lxc

CGroups : https://linuxism.tistory.com/1601

Namespace : http://jake.dothome.co.kr/namespace/

Dockerfile 연습을 위해 작성

Dockerfile

FROM ubuntu

MAINTAINER noname

RUN apt-get update
RUN apt-get install -y apache2
RUN apt-get install -y apache2-utils

RUN echo "ServerName localhost" >> /etc/apache2/apache2.conf
RUN sed -i 's/80/1111/g' /etc/apache2/ports.conf # 원하는 포트넘버로 바꿔줌

CMD ["/usr/sbin/apache2ctl", "-D", "FOREGROUND"]

docker build -t noname/apache2 .
docker run -d -p 1111:1111 noname/apache2

Dockerfile : 이미지를 생성하기 위한 스크립트이다.

아래에서 기본적인 커맨드들을 설명할 것이다.

1. Dockerfile

1) FROM

어떤 이미지를 기반으로 새로운 이미지를 생성할 것인지를 나타낸다.

2) RUN

이미지를 생성할 때 실행할 코드를 지정한다.

3) WORKDIR

작업 디렉토리를 지정한다. 없다면 새로 생성한다. 지정 이후 명령어는 해당 디렉토리를 기준으로 실행된다.

4) COPY

파일이나 폴더를 이미지에 복사한다.

아래 예시에서는 test.txt파일을 test2.txt라는 이름으로 복사한다.

5) ADD

호스트의 파일 시스템으로부터 파일을 가져온다.

6) ENV

이미지에서 사용할 환경변수 값을 지정한다.

6) ENTRYPOINT

컨테이너가 시작되었을 때 실행된다. 즉 docker run으로 컨테이너를 생성하거나 docker start로 정지된 컨테이너를 시작할 때 생성된다.

7) CMD
ENTRYPOINT와 비슷하지만, docker run 명령에서 실행할 파일을 설정하면 CMD는 무시된다.

docker run ubuntu echo world

2. 이미지 생성

# docker build -t <생성될 이미지 이름> <Dockerfile의 위치>

docker build -t noname:0.1 .

3. 예제

FROM ubuntu:latest

RUN echo "hello, dockerfile!"
RUN mkdir /testDockerFile

WORKDIR /
COPY test.txt test2.txt

CMD ["echo", "hello"]

실행 결과는 다음과 같다.

생성한 이미지를 가지고 컨테이너를 실행해보자.

noname:0.1을 그냥 실행하면 CMD가 실행된다.

그러나 /bin/bash를 실행시키면 CMD가 무시된 채로 /bin/bash가 실행된다.

이때 Dockerfile의 RUN echo "hello, dockerfile!"은 실행되지 않는 것처럼 보인다.

그러나 RUN 커맨드 자체가 빌드 과정에서 실행되는 것이기 때문에, 컨테이너 생성 시에는 실행되지 않는 것이 당연하다.

빌드 과정을 보면 Step 2에서 hello, dockerfile!을 출력한 것을 볼 수 있다.

컨테이너 업데이트 : 기존 컨테이너 삭제(stop -> rm) 후 새 버전의 이미지를 다운(pull)해서 실행(run)

컨테이너를 삭제하면 컨테이너에서 생성된 파일은 삭제된다. 예를 들어, mysql 컨테이너에서 데이터를 쌓았다면 그 데이터들이 모두 사라진다.

이것을 방지하기 위해서는 데이터를 컨테이너 내부가 아닌 외부 스토리지에 저장해야 한다. 두 가지 방법이 있는데, 하나는 클라우드 서비스를 이용하는 것이도 하나는 Data volumes를 컨테이너에 추가해서 사용하는 것이다.

#1에서 정리한 옵션 중에 -v가 있다. 이 방법을 사용할 것이다.

-v 옵션을 사용해서 /Users/ksign/Desktop/testvol 폴더를 컨테이너의 /var/lib/mysql 폴더에 마운트했다.

#1에서 실행한 ubuntu에 변경사항을 추가해보자.

여기서는 git을 설치할 것이다.

# docker diff {container}

// 실행중인 docker는 내버려두고 다른 powershell을 띄워서 확인하면 컨테이너를 생성한 부모 이미지와 다른 점이 무엇인지 출력해줌

# docker commit {container} {imagename:tag}

// 새로운 이미지를 생성함

commit 후 확인해보면 설정한대로 이미지가 생성된 것을 확인할 수 있다.

생성한 이미지로 컨테이너를 실행해보면 git 설치를 확인할 수 있다.

# docker stop {container}

// 실행중이지만 접근중이진 않은 컨테이너들을 exited 상태로 전환할 때 사용함

# docker rm {container}

// exited 상태인 컨테이너를 제거함

# docker rmi {image}

// 컨테이너가 존재하지 않는 이미지를 제거함

띄워쓰기로 여러개의 이미지들을 한꺼번에 제거할 수 있다.

# docker search {image}

// docker public registery에 등록된 공개 이미지를 검색

# docker pull {image}

// 이미지 다운

# docker images

// 시스템에 다운받아져 있는 이미지 목록

아까 다운받은 ubuntu가 존재함을 찾아볼 수 있다.

# docker run {option} image[:tag|@digest] {command} {arg...}

// 컨테이너 실행

옵션을 넣고 docker를 실행하면 정상적으로 컨테이너가 생성됨을 알 수 있다.

exit로 bash쉘을 종료하면 컨테이너도 같이 종료된다.

# docker ps

// 현재 실행중인 컨테이너 목록 출력

# docker ps -a

// 죽은 컨테이너 목록도 함께 보여줌

# docker restart {container}

// 죽은(exited) 상태인 컨테이너를 되살림

그러나 이 경우 /bin/bash가 실행되지는 않는다.

도커 ID의 전체 길이는 64자리이지만 명령어의 인자로 전달할 때는 다른 컨테이너와 겹치지 않는만큼만 입력해도 된다. 예를 들어 ID가 abcdef인 컨테이너와 abdce인 컨테이너가 있다면 abc까지만 입력해도 abcdef 컨테이너로 인식한다.

# docker attach {container}

// 다시 컨테이너 안으로 들어감

* exited 상태인 컨테이너에 바로 쓸 수는 없고 restart한 뒤 사용 가능하다.

Docker?

컨테이너 기반의 오픈소스 가상화 플랫폼이다.

Virtual Machine과 상당히 유사하면서 훨씬 가벼운 형태로 배포가 가능하다.

Image : Dock의 최소 관리 단위. 이 이미지로부터 컨테이너가 실행된다.
Container : 이미지로부터 만들어진 실행중인 도커 프로세스이다.

Container

개별 소프트웨어의 실행에 필요한 실행환경을 독립적으로 운용할 수 있도록 기반환경 또는 다른 실행환경과의 간섭을 막고 실행의 독립성을 확보해주는 운영체제 수준의 격리 기술이다. 프로세스를 실행하는데 필요한 모든 정보들은 이미지에서 제공하기 때문에 개발, 테스트, 배포까지의 모든 단계에서 일관성을 유지한다.

아래 그림과 같이, docker에서는 app과 app에 필요한 바이너리/라이브러리만 올라간다. 이것을 합쳐 컨테이너라고 한다.

Image

이미지는 컨테이너 실행에 필요한 파일과 설정값 등을 포함하고 있는 것으로 불변한다. (read-only)

컨테이너는 이미지를 실행한 프로세스이고 실행 후 추가되거나 변하는 값은 컨테이너에 저장이 된다. (read-write)

컨테이너의 상태를 변경하거나 컨테이너를 삭제해도 이미지에는 영향이 없다.

하나의 이미지로 여러개의 컨테이너를 생성할 수 있다.

도커 이미지는 Docker hub(hub.docker.com)에 등록하거나 Docker Registry 저장소를 직접 만들어(docs.docker.com/registry/) 관리할 수 있다.

Layer

이미지는 여러 개의 read-only 레이어로 구성된다.
컨테이너를 생성할 때는 이미지 레이어 위에 read-write 레이어를 추가한다.
파일이 추가되거나 수정되면 새로운 레이어가 생성된다. 

업데이트시 새로 추가된 레이어만 받아온다.

VM이 전체 이미지를 매번 받아와야 했던 것과 비교해서 효율적이다.

Virtual Machine vs. docker

VM과의 유사점: 호스트 운영체제에서 구동되면서 소프트웨어 서비스 구동을 위한 격리 환경을 마련해준다.

Hypervisor 기반의 단점
    불필요한 기능의 중복 : Host OS와 Guest OS 간의 기능 중복
    상대적 무거움 : 오버헤드가 많이 발생
    가상화 머신 배치의 어려움 : 여러 개의 가상화 머신을 띄우는 경우 어렵다

Virtual Machine은 하드웨어와 그 위에 올라가는 운영체제를 가상화한다.

운영체제를 포함한 거대한 이미지를 배포해야하기 때문에 자원(CPU, memory, disk)을 많이 잡아먹는다.

가상머신 안의 프로그램을 실행하기 위해서는 운영체제를 실행하는 과정을 거쳐야 하기 때문에 시간도 그만큼 소모된다.

Docker는 하드웨어를 추상화하지 않고 도커를 실행한 운영체제의 자원을 모두 공유한다.

사실상 프로세스로 간주되어 자원을 효율적으로 사용할 수 있고, 운영체제를 실행하는 과정이 없는 만큼 빠르다.

그러면서도 가상화의 장점인 네트워크, 디스크, 유저 격리를 할 수 있다.

원문 : https://digital-forensics.sans.org/blog/2011/03/14/digital-forensics-understanding-ext4-part-2-timestamps

다행히 part1은 이미 번역이 잘 되어 있다. (https://behonestar.tistory.com/9)

Setting tue Stage

Ext4 파일 시스템에서 다른 테스트 파일을 설정해보자.

atime과 mtime 값을 명시적으로 보기 위해 root 권한에서 touch 명령어를 사용할 것이다. 이는 몇몇 흥미로운 타임스탬프 값을 확인하기 위해서이다. 그렇지 않으면 모든 타임스탬프가 새 파일을 만든 순간으로 설정될 것이다. 여기서 한가지 주의해야 할 점은 atime과 mtime 둘 다 먼 미래의 날짜로 설정하고 있다는 것인데, 오래된 Unix 파일 시스템에서는 일반적으로 32비트 date rollover 이슈(또는 "2038년 문제"로 불리는 것)로 인해 문제가 발생할 것이다.

자, 이제 표준 linux stat 명령의 출력값과 Sleuthkit의 istat의 출력값, debugfs의 stat 버전을 비교해보자:

타임스탬프에 더 쉽게 집중할 수 있게 출력값을 편집했다. 보다시피, 세가지 명령들은 기본적으로 mtime과 ctime 값에 동의한다. 그러나 stat 명령어는 2111의 atime 값을 정확히 해석하지만, istat과 debugfs stat는 모두 그것을 해석하는 데 문제가 있다.

너는 아마 Ext4의 다른 새로운 기능도 발견했을 수 있다: 

• Stat와 debugfs stat 명령어는 소수 타임스탬프 값을 지원한다. 이제 Ext4는 파일 타임스탬프에서 ns「nanosecond」 해상도를 지원한다.
• Debugfs stat 출력값에 "crtime" (create time) 타임스탬프가 있다. Ext4는 마침내 NTFS같은 "born on" 시간 (btime)을 지원한다. 디스크 볼륨 내에 파일이 생성되었을 때를 위한 타임스탬프를 지원하기 위해서이다.
• 그리고 stat과 touch 둘 다 적어도 먼 미래의 날짜는 완벽하게 받아들일 수 있을 것으로 보인다. Ext4가 2038년 문제를 고친 것 같다.

Eet4는 64비트 타임스탬프 필드로 이동함으로써 이 기능들의 많은 부분을 제공했다. 이는 ns 타임스탬프를 지원하기에 충분한 해상도를 제공하며, 여전히 몇 개의 비트가 남아 있어 미래까지 날짜를 지정할 수 있다.

Show Me the Bits

이전 편에서 언급했듯이 Ext4 개발자들은 Ext2/Ext3의 inode 레이아웃과의 역호환성을 유지하기 위해 매우 열심히 노력했다. 그러나 64비트 타임스탬프와 완전히 새로운 파일 생성 타임스탬프는 분명히 이 목표를 어렵게 한다. Ext4 개발자들은 이 문제를 새로운 256비트 Ext4 inode의 상위 128비트에 추가하여 해결했다.

Hex editor 보기 ( 정확한 inode의 파일 카빙 프로세스는 Part 1을 참조 ):

inode의 시작을 0부터 계산하면, 다음은 다양한 강조 표시된 필드에 대한 바이트 오프셋과 의미이다:

Inode 시작 근처의 표준 MAC 시간 값은 기본적으로 변경되지 않는다. 1970년 1월 1일(unix "epoch"라는 이름) 이후 초를 저장한다. 그러나 Ext4는 이러한 값을 요청된 원래 Unix 파일 시스템 규격으로 서명된 값이 아니라 서명되지 않은 정수로 처리한다. 여분의 비트를 사용하면 실제로 "2038년 문제"를 "2106년 문제"로 바꿀 수 있다.

실제로 2040년도의 mtime 값으로 이것을 볼 수 있다. inode가 사용하는 리틀 엔디안 형식에서 변환하여, 16진수 mtime 값은 0x845E5913 또는 십진수 2220775699-32비트 서명 값에서 rollover를 유발하는-이다. (※ You can actually see this in action with our mtime value from the year 2040. Converted from the little-endian format that the inode uses, our hex mtime value is 0x845E5913, or 2220775699 decimal- a number that would normally cause roll-over in a 32-bit signed value. 제대로 된 해석이 아닌 것 같아 원문 첨부) 이 십진수 값을 작은 쉘 magic과 GNU date 명령으로 사람이 읽을 수 있는 날짜로 변환할 수 있다:

아까의 stat 결과값과 비교해보면 정확한 값을 계산한 것을 알 수 있다.

But Wait! There's More!

그러나, inode의 상위 128바이트에는 각 MAC 타임스탬프에 대해 "extra" 32비트가 있다. 여기에 해당 색상으로 표시했기 때문에 매칭하기 쉽다. "extra" 필드를 각 타임스탬프의 ns부분으로 생각할 수 있다. 하지만 실제로는 ns 해상도를 나타내기 위해 30비트만 있으면 된다. 그래서 "extra" 장면의 상위 30비트는 ns이지만, 나머지 2비트는 실제로 inode의 초기 부분의 seconds field를 확장하는 데 사용된다.

헷갈린다면 2111년의 atime 값을 예로 들어보자. 표준 atime bytes 8-11을 살펴보면 16진수 값이 0x0954B156 또는 156545366이 될 것이다. 이를 날짜 문자열로 변환하면:

이제 istat과 debugfs stat이 잘못 출력하고 있는 곳을 볼 수 있다. 그들은 inode 초기 때부터 표준 32비트 atime 값을 변환하고 있을 뿐이다.

하지만 우리가 "extra" atime 필드에서 두 비트를 낮은 순서로 더하면 어떻게 되는지 봐라. "extra" atime 필드의 low-order 바이트는 2진수로 0x01 또는 "00000001"이다. 그래서 low-order 2비트는 "01"이다. 우리는 표준 atime 값 앞에 이 추가 비트를 미리 붙인다. 그래서 실제 atime는 0x010954B156으로, 10진수 4451512662이다. 이제 우리는 그것을 인간이 읽을 수 있는 스트링으로 변환한다:

빙고! 우리의 touch 명령과 stat 출력값에 매칭되는 정확한 날짜가 있다.

extra 2비트로 나타낼 수 있는 가장 큰 값은 0x03FFFFFFFF, 즉 십진수 17179869이다. 이로써 GMT의 날짜는 2514-05-30 01:53:03이며 이는 확실히 우리의 날짜 rollover 문제를 훨씬 더 멀리 미뤄주고 있다. 하지만 우리가 실제로 ns 파일 타임스탬프 해상도가 필요한지는 확실하지 않다. 나는 Ext4 개발자들이 덜 정밀하게 선택해서 우리의 타임스탬프의 수명을 늘리기 위해 나에게 2-6비트를 더 줬으면 좋겠다. 반면에, 2514년까지 이 중 어느 것도 아마 중요하지 않을 것이다. (※ I wish the EXT4 developers had chosen less precision and given me another 2-6 bits to extend the lifetime of our timestamps. On the other hand, by 2514 none of this will probably matter anyway.)

Fractional Seconds

각 타임스탬프의 "extra" 비트의 재미있는 packing은 여러분이 각 타임스탬프의 ns 구성요소에 관심이 있을 때 상황을 더 복잡하게 만든다. 새 생성 시간 필드를 예로 들어보자. 생성 시간 초와 생성 시간 "extra" 필드에 필요한 64비트는 새로운 대형 Ext4 inode의 상단 부분에 보관된다. 그것들은 다른 타임스탬프의 "extra" 필드 바로 뒤에 나타나며 위의 그림에서 두 가지 색조의 파란색으로 강조된다.

생성 시간 "extra"의 16진수 값은 0x148이다. AF06C, 또는 344649836. 그러나 low-order 2비트는 ns를 세는 데 사용되지 않는다. 우리는 그 비트들을 버리고 모든 것을 2비트씩 바로 옮겨야 한다. 이것은 4로 나누는 것과 같다. 따라서 우리의 실제 ns 값은 344649836 / 4 = 86162459이다.

우리는 변경 시간 "extra" 필드에 대해서도 같은 일을 할 수 있다. 16진수 값 0xCFFFBE18는 십진수로 3489644056이다. 4로 나누면 872411014가 나온다. 글의 앞부분에 나온 stat 결과값을 다시 참조하면, 계산된 값이 ctime에 대해 보고된 fractional seconds와 일치한다는 것을 알 수 있다.

Wrapping Up For Now

이 시점에서 우리는 대부분의 사용자에게 영향을 미치는 주요 Ext4 inode 변경사항, 즉 extent와 새로운 타임스탬프 형식을 다루었다. 그러나 제 1부의 extent에 대한 논의는 표준 Ext3 inode에서 사용 가능한 4개 이상의 extent 구조가 실제로 필요할 때 발생하는 문제를 건너뛰었다. 그것은 이 시리즈의 다음 편에서 주제가 될 것이다.

19.07.11
한동안 쉬었던 렌파이 다시 시작.~미니게임_짝맞추기
textbutton으로 카드 만들면 될 것 같은데...
[+] imagebutton ~ action ... 으로 image를 뒤집을 수 있을 것 같다.
[+] 작업 진척
이미지 클릭 시 다른 이미지로 바뀌는 것까지 하는데 제법 오래 걸렸고(이 기능이 없는 줄 알고 파이썬으로 구현하고 있었는데 있었던...삽질 오지게 했네)
앞으로는 이 기능 상에서 A이미지를 열고 B이미지를 열었을 때 바뀐 이미지를 되돌리고 똑같은 A이미지를 열었을 때 그대로 두는 기능을 구현할 건데 될지 안될지 알 수가 없음 아직까진 결과 없이 삽질중