6/27/2018

minikube 실습하기

minikube 실습하기

Minikube Quickstart를 해보았습니다.

Minikube 란?

Minikube는 쿠버네티스를 로컬에서 쉽게 돌리게 하는 툴입니다. Minikube는 쿠버네티스를 사용해보거나, 매일 (쿠버네티스를) 개발하는 사람을 위해, 싱글 노드 쿠버네티스 클러스터가 당신의 컴퓨터 위의 VM에서 돌아갑니다.

Installation

  • macOS
brew cask install minikube
이 결과로 사용할 수 있는 명령어
  • kubectl
  • minikube
kubectl is a command line interface for running commands against Kubernetes clusters. This overview covers kubectl syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the kubectl reference documentation. For installation instructions see installing kubectl.

Quick Start

  • minikube start: ISO 다운와 함께 시작
  • minikube version: v0.28.0
  • kubectl version: 쿠베컨트롤의 버전을 확인합니다.
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.5", GitCommit:"32ac1c9073b132b8ba18aa830f46b77dcceb0723", GitTreeState:"clean", BuildDate:"2018-06-22T05:40:33Z", GoVersion:"go1.9.7", Compiler:"gc", Platform:"darwin/amd64"}
The connection to the server 192.168.99.100:8443 was refused - did you specify the right host or port?
  • minikube get-k8s-versions: 가능한 쿠버네티스 버전들을 보여줌. v1.10.0 이 최신
  • minikube start --kubernetes-version="v1.10.0"
  • minikube ssh
    • uname -a
$ uname -a
Linux minikube 4.16.14 #1 SMP Mon Jun 11 16:20:15 UTC 2018 x86_64 GNU/Linux
  • kubectl cluster-info
Kubernetes master is running at https://192.168.99.100:8443
KubeDNS is running at https://192.168.99.100:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
  • kubectl get nodes
NAME       STATUS    ROLES     AGE       VERSION
minikube   Ready     master    37m       v1.10.0
  • kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.4 --port=8080
deployment.apps "hello-minikube" created
  • kubectl expose deployment hello-minikube --type=NodePort
service "hello-minikube" exposed
  • kubectl get pod
NAME                             READY     STATUS              RESTARTS   AGE
hello-minikube-6c47c66d8-5sz78   0/1       ContainerCreating   0          14s
  • curl $(minikube service hello-minikube --url)
Waiting, endpoint for service is not ready yet...
Waiting, endpoint for service is not ready yet...
CLIENT VALUES:
client_address=172.17.0.1
command=GET
real path=/
query=nil
request_version=1.1
request_uri=http://192.168.99.100:8080/

SERVER VALUES:
server_version=nginx: 1.10.0 - lua: 10001

HEADERS RECEIVED:
accept=*/*
host=192.168.99.100:32584
user-agent=curl/7.54.0
BODY:
-no body in request-%
  • minikube ip 192.168.99.100
  • curl $(minikube service hello-minikube --url) -d '{data:data}'
CLIENT VALUES:
client_address=172.17.0.1
command=POST
real path=/
query=nil
request_version=1.1
request_uri=http://192.168.99.100:8080/

SERVER VALUES:
server_version=nginx: 1.10.0 - lua: 10001

HEADERS RECEIVED:
accept=*/*
content-length=11
content-type=application/x-www-form-urlencoded
host=192.168.99.100:32584
user-agent=curl/7.54.0
BODY:
{data:data}%
  • http -f POST $(minikube service hello-minikube --url) API-key:foo hello=world
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/plain
Date: Wed, 27 Jun 2018 12:38:44 GMT
Server: nginx/1.10.0
Transfer-Encoding: chunked

CLIENT VALUES:
client_address=172.17.0.1
command=POST
real path=/
query=nil
request_version=1.1
request_uri=http://192.168.99.100:8080/

SERVER VALUES:
server_version=nginx: 1.10.0 - lua: 10001

HEADERS RECEIVED:
accept=*/*
accept-encoding=gzip, deflate
api-key=foo
connection=keep-alive
content-length=11
content-type=application/x-www-form-urlencoded; charset=utf-8
host=192.168.99.100:32584
user-agent=HTTPie/0.9.9
BODY:
hello=world

5/14/2018

Pyenv-virtualenv + virtualenvwrapper + autodir

Pyenv-virtualenv + virtualenvwrapper + autodir

배경

  • 오랜만에 Django project를 하나 만들어 볼까하는데 환경설정이 항상 문제다.
  • 그저 프로젝트 폴더에 virtualenv 만들어서 개발할 때마다 activate를 할수 있을 것이다.
  • 그런데 이게 괜히 불편해서 폴더 들어가면 자동으로 virtualenv를 activate 시켜주고 싶어졌다.
  • 사실 vagrant나 docker로 띄우면 개발환경이 아예 격리되기에 위같은 고민을 한번에 해결할수 있었을 것이지만…
아무튼 하기로 한거니 해보려고 했다.

문제와 목표

문제 1. virtualenv 폴더를 매번 찾기 귀찮다.

  • virtualenvwrapper를 이용하여, 한곳에 가상환경을 몰아넣고 alias로 가상환경을 불러온다.

문제 2. 해당 alias를 project name과 같게 해야하거나 기억해야한다.

문제 3. 개발할 때마다, CLI로 매번 가상환경을 불러와야함

  • 프로젝트 폴더 들어갈 때, 자동으로 virtualenv를 activate
  • (중요) 나갈때는 deactivate
반복되고 실수할 수 있는 것을 줄이자

결과

Zsh-autoenv를 사용하여 해결함

  • env file이 변경되면 처음에만 실행할 건지 묻게 됨
  • pyenv versions가 한줄에 표시되어 가독성이 좋지 않은 건 일단 넘어갔음
~/projects $ cd starbucks-between-us
Attempting to load unauthorized env file!
-rw-r--r--  1 erwre  staff  48  5 14 19:06 /Users/erwre/projects/starbucks-between-us/.autoenv.zsh

**********************************************

pyenv activate starbucks
echo $(pyenv versions)

**********************************************

Would you like to authorize it? (type 'yes') yes
system 3.6.4 3.6.4/envs/starbucks * starbucks (set by PYENV_VERSION environment variable)
~/projects/starbucks-between-us $
~/projects/starbucks-between-us $ cd ..
Attempting to load unauthorized env file!
-rw-r--r--  1 erwre  staff  40  5 14 19:07 /Users/erwre/projects/starbucks-between-us/.autoenv_leave.zsh

**********************************************

pyenv deactivate
echo $(pyenv versions)

**********************************************

Would you like to authorize it? (type 'yes') yes
system * 3.6.4 (set by /usr/local/var/pyenv/version) 3.6.4/envs/starbucks starbucks
~/projects $

과정

기존 개발 환경은 pyenv로 python 3.6.4를 global default로 사용 중이었다. 터미널은 iTerm+Zsh 조합을 쓰고 있다.
  1. smartcd : 설치가 번거로움
  2. direnv : directory를 벗어날 때, 적을 수 있는 스크립트 옵션이 없어보임( 예시에서는 폴더 들어갈 때, 스크립트에서 환경변수를 export 함. 폴더를 빠져나오니 사라지는 정도의 환경변수 정리만 지원하는 것으로 보임)
    • brew install로 설치 시, repo master와 버전이 다름
      • env.leave 기능(폴더 빠져나올 때 실행할 스크립트)을 지원하지 않음
    • pip로 설치하기에는 pyenv에 있는 특정 버전에만 설치되어 꼬일까봐 brew로 최대한 설치하려 했음
      • 합리적인 의심이 맞는건가?
      • 어차피 가상환경들어가서도 deactivate는 될텐데?
      • 그건 virtualenv로 생성된 환경이라 가능한거 아닌가라고 생각되었고 pip로 일단 시도는 안해봄
    • 성공!
    • zsh를 위해 autoenv를 wrapping 함
    • env.leave 기능이 반영되어 있어서 사용함
      • 정확히는 .autoenv.zsh.autoenv_leave.zsh로 파일 이름이 다름
    • 다만 설치는 brew나 pip를 사용할 수 없어 repo clone 해야함
      • 업데이트 시점을 알수 없어 버전 관리에 취약할 수 있음
      • git pull로 할수도 있지만, brew update나 pip update에 비하면 개별적인 패키지 관리는 번거롭다.

Furthermore

  • pyenv-virtualenv와 virtualenv 어느 것을 쓰는 게 적합할까?
    • pyenv에서 제공하는 virtualenv는 해당 pyenv를 들어가지 않고도 한눈에 확인이 가능하다.
    • 그래서 pyenv-virtualenv를 사용함
  • pyenv-virtualenv: prompt changing will be removed from future release. configureexport PYENVVIRTUALENVDISABLE_PROMPT=1' to simulate the behavior.`
    • pyenv-virtualenv에서는 prompt에서 가상환경을 변경하는 것을 제거할 예정이라고 함…
    • 왜일까는 덜 살펴보았는데, 쉘 환경마다 prompt 앞에 붙던 가상환경의 alias가 문제가 된 것으로 보인다. (대충 살펴봐서 정확하지 않습니다. 너무 발산하는 거 같아서 풀고자 하는 것에 집중했음)
    • 일단은 prompt 옵션을 ~/.zshrc에서 바꾸도록 했음
    • 아쉬운 건, activate 되었는지 prompt 상에서 확인하기가 어렵다는 것인데, autudir에서 pyenv version을 echo로 출력하면 쉽게 해결됨
  • pyenv-virtualenv로 가상환경을 만들면 pyenv versions에 두개가 추가된다. 사용중인 pyenv의 환경을 기반으로 virtualenv를 만들고 alias를 두는 형태로 보인다. 모르고 비활성화된 한쪽을 지웠다가 오류가 났음
$ pyenv versions
  system
  3.6.4
  3.6.4/envs/starbucks
* starbucks (set by PYENV_VERSION environment variable)

$ which python
/usr/local/var/pyenv/shims/python

$ pyenv which python
/usr/local/var/pyenv/versions/starbucks/bin/python

$ ll /usr/local/var/pyenv/versions
total 0
drwxr-xr-x  7 erwre  admin   224B  5 11 17:08 3.6.4
lrwxr-xr-x  1 erwre  admin    50B  5 11 18:00 starbucks -> /usr/local/var/pyenv/versions/3.6.4/envs/starbucks
  • 다른 사람과 협업하기에 개발 환경이 내 환경에 너무 의존적이지 않은가?
    • requirements.txt로 의존성 관리를 하여, pip install -r requirements.txt는 명시적으로 실행될 거기 때문에 문제가 되지 않음
    • dockerfile을 이용하여, 이 과정을 줄일 수도 있음
  • (추가 아이디어) pip freeze > requirements.txt를 프로젝트 폴더 빠져나갈 때마다 실행하면 어떨까?
    • 테스트 중이고 의도되지 않은 패키지들이 반영 될수도 있지만, 그건 commit을 안하면 될 문제고, 패키지 변경을 알려주는 측면에서는 더 좋지않을까?!
    • cd .. 를 이미 한 시점에서 pwd는 project 상위 폴더를 가리키고 있음
    • 그리고 보통 cd ..로 종료 안하고 터미널 자체를 끄거나 새로운 터미널 세션을 사용하는 경우가 많아 의도대로 프로젝트 종료 시점과는 일치하지 않을 수 있음
    • 프로젝트 진입 시점(는 매번 호출)으로 바꿔도 큰 문제가 없을거 같음

2/08/2018

이직을 위한 생각을 정리해보자


(계속 업데이트 될 예정)



글을 쓰게 된 계기


프런트엔드 개발자가 되고 싶지 않았던 프런트엔드 개발자의 이직기를 보고 놀다가 아무 행동도 하지않고 불안감에만 빠져있는 스스로를 반성하며


현재 상태



0. 사이버대학원 입학으로 민간인의 신분을 유지 중
1. 9월부터 쭉 쉬었음(경력 단절의 위험...) → 학업을 이유로 때우면 어떻게 되지 않을까? → 그럼 신입 ^^
2. 끌리는 비지니스가 있는 회사가 번뜩 생기지는 않는다는걸 깨달음 → 스스로 이해하고 찾으려는 노력을 해야함 → 사람을 만나되 스스로 생각을 정리하고 만나자
3. 이제 백수로 살기에는 돈이 없다. 먹는게 행복인 사람으로써 가난한 백수는 힘듬.
4. 매우 심심함! 사람이 고픔. 원시인도 이것보다 대화를 많이 했을 거다.


퇴직으로 배운 것



1. 측정 가능한 평가 : 실적을 내기 위해 목표 설정이 필요하고 그에 대한 협력을 해나아가 미치지 못한 점은 반성하고 목표 설정과 변경된 목표에 대해서도 회고할 수 있는 업무 프로세스가 필요하다고 느꼈다. 이전 회사에서는 성과 평가 때마다 모호하고 딱히 평가라고 하기도 어려운 페이스북의 좋아요 버튼중 뭐를 고를까 하는 정도의 느낌이였다. 평가자가 아닌 내가 그 노력을 무시하는 건 아니지만 피드백을 받아 개선하기 충분한 이유가 되지 못했다. (그래서 "제가 뭘 못했고 더 하면 좋을까요" 라는 질문에 "나도 모르겠는데 더 해야해"는 참 인생에 남을 답변이다.)

2. 명확한 목표 : 내가 무언가를 처리하거나 해냈을 때, 완료 되었는지 정도를 파악할 수 있고 구성원들간에 동의가 가능한 기준이 필요하다. 여기 문제가 있어서 해결했을 때, 문제가 해결되어 무엇이 개선되었는지 새로운 문제를 낳지 않았는지 따지지 않으면 제자리에서 쳇바퀴만 굴러가는 꼴이 된다. 그래도 비지니스가 성장할 수 있겠지만 개인의 성장은 없을 것 같다. 인지 가능한 성장(마이너스라도)이 필요하다.그래야 다음 행동을 할 수 있기에. 덧붙여, 위의 측정 가능한 평가가 이뤄질 수 있는 기반이다.

3. 협업이 있는 업무. 배울 수 있는 동료 : 제일 무서운 게 익숙해지는 거라고 했던가. 연애와 자주 비교되는 일도 마찬가지다. 익숙해지면 새로 배우지 않게 되고, 혼자만 일하면 객관적으로 판단하기가 힘들다. 계속 타인의 시선으로 나를 볼 수 있고 서로 성장할 동료들이 있는 환경이 필요하다. 딱딱한 규칙을 만들기는 싫지만 서로 다른 생각을 감정이 아닌 충분한 이해와 설명으로 같이 해나갈 수 있는 꼼꼼함을 원한다. 이를 시간 낭비로 여기는 사람이 있다면 서로 과거와 현재를 탓하는 악순환의 고리에 빠진다. 미래를 논할 수 있는 비난하지 않는 건강한 토론이 고프다.

결국 위의 조건을 정리하면 업무 프로세스의 선순환으로 요약 가능한데 흔히들 스타트업은 그런거 기대하면 안된다고들 한다. 그렇다고 대기업이라고 다른 것도 아니라고 한다. 그럼 좀 더 유연한 스타트업에서 기대하거나 만들어 나가는게 맞다고 생각한다. 내가 맞는 역할을 찾아나가는게 스타트업이 유연하기도 하다.


이외의 생각 중인 기준들



어떤 비즈니스? B2B? B2C?



사실 비지니스가 끌리냐 안끌리냐는 해보지 않고선 모르는 일 같다. 조건만 많아지니 일을 하기 싫은 것밖에 안되는거 같아서 내가 겪지 못한 것을 하나씩 해치워나가는 것을 목표로 삼고자 한다.

단 하나, 경험으로 부터 원하는 바가 있다면 늘리고 싶어도 늘릴 수 없는 B2B는 피하고 싶다. 거래액이나 유저의 숫자가 모든 걸 말해주진 않지만 결국 인력이나 기업의 예산에 따라 결정되어 스케일업 할 수 없는 비즈니스는 짧은 경험상 개발자로 성장이 막히는 때가 올 수밖에 없다고 생각한다. 구체적으로는 세일즈 파워로 결정되거나 비즈니스를 처리하는 사람의 역량과 수에 결정되는 것을 말한다.

아는 사람이 있는 회사가 좋을까?



이건 케바케라서 답이 딱 떨어지지 않는다. 사람 나름이고 나랑 캐미도 중요할 것이다. 다른 구성원이 그 사이를 매꿔줄수도 있고 같이 일하지 않는다면 큰 차이가 안날 수도 있다. 이전의 경험이나 주변 사람들의 의견도 중요하지만 직접 일하지 않은 사람을 미리 판단하여 기회를 미리 단절시키지는 않도록하자.

나는 어떤 스테이지에 어울리는 사람일까? 어떤 곳에 능하고 부족할까?




7/31/2015

Windows에서 Python3 virtualenv 셋팅하기

Python2가 이미 있고, virtualenv를 설치했다면 virtualenv command는 Python 2.x 기준으로 환경을 만든다.

아래와 같이 cmd에서 명령어를 입력하면, 3.x의 virtualenv 환경을 사용할 수 있다.

Git bash에서 입력하면 아래와 같은 오류를 얻는데, powershell 같은 종류는 다른 처리가 필요하다고 한다.


pip uninstall virtualenv를 하면 2.x 의 library는 제거되어, 3.x를 기본으로 사용할 수는 있다.

Ref: The Python Standard Library » 28. Software Packaging and Distribution » 28.3. venv — Creation of virtual environments

7/27/2015

Window terminal : ConEmu + Git bash

클린 코드를 위한 테스트 주도 개발을 읽으며, git bash를 쓰게 되었는데 투박하고 탭 기능을 지원하지 않아서 아쉬웠다.
working session 그대로 탭 복사하는 기능까지 되었으면 하였다. 이는 다음 포스팅으로 생각 중이다.

알아보니 ConEmu가 있었다. Terminal wrapper 같은 것으로 git bash를 내부에서 띄워주고 탭 관리를 가능하게 했다.




설치하기



  1. Git bash를 설치
  2. ConEmu를 설치
  3. ConEmu를 열고, settings를 열음
  4. Settings 목록에서 startup - tasks를 열음
  5. 새로운 task를 만들거나, 기존의 것을 수정 
    • "[git directory]\bin\sh.exe --login -s"
    • Hot Key를 등록
위에서 나는 조금 다르게 했는데, 
  • 4번 대신에 Bash::Git bash의 Hot key만 등록하고
  • Startup 메뉴에서 Specified named task를 {Bash::Git bash}로 선택
  • 하여 기본적으로 Git bash가 실행되도록 함. default는 cmd

그러면 Git bash를 기본으로 하는 탭 생성키까지 설정이 완료 된다.


폰트 적용



한글과 영어를 모두 지원하는 폰트를 설치하고 (위 링크의 Monaco 추천)

Settings의 Main에서  Main console font를 변경한다.


한글 입력 문제

??? 으로 표시되는 입출력 문제는 ConEmu 한글 + 폰트 참고

뭔가 잘못건드리지 않는한 기본적으로 잘 된다. (git bash 환경) 

=> 필자는 뭔가 잘못했다   

Vim 저장 때문에 이것저것 만지다가 terminal 상에서 set encoding 명령어를 실행했는데 

이게 유효한 건지는 모르겠지만, 보통 일어나는 ??? 로 표시되는 한글 문제가 아니라

Ϸፊ**ġ *Ϸሄ ō*α* 같이 표시되었다.

출력은 괜찮은데 terminal 상의 한글 입력만이 문제였다.


결국은 git을 다시 설치하여 git bash 설정을 초기화 했다.

user setting 파일인 ~/.bashrc와 ~/.inputrc는 바뀐 내용이 없었지만 다시 한글 입력이 가능해졌다.



Vim 한글 저장 문제

잘쓰던 참에 한글 주석을 적어서, selenium을 돌리다가 encoding 문제가 발생하였다.

py 파일에 encoding 선언도 하였는데 문제가 발생한 이유는 vim에서 utf-8로 저장하지 않아 한글이 깨졌기 때문이다.

표시는 잘되나, 저장 후 cat을 했는데 잘 안나오면 vim에서 파일 저장시 사용하는 인코딩 문제이다.

이는 아래와 같이  $ vim ~/.vimrc 로 vim 설정 파일을 만들어주면 된다.


tenc는 terminal의 encoding을 의미. 
vim 상에서는 :set termencoding=utf-8 로 설정 가능하다. 하지만 vim 에서 설정하면 그 때만 유효하다. 

enc는 vim으로 열 파일의 encoding을 의미. 값을 확인하고 싶으면 vim에서 :set encoding?

즉, utf-8 파일을 열어서 터미널의 encoding인 korea로 맞추라는 뜻이다.


마무리


한글 처리에 아주 삽질을 해서, 인코딩 시점으로 덕분에 터미널 위에 돌아가는 것들의 구성을 느낄 수 있었다.

그래도 나름 한번 정리를 해놓으니 나중에 덜 고생을 할 것이라고 믿는다.


Ref 

[Python] / operator와 // (floor division) operator의 차이

// (floor division) 는 2.2 부터 도입됨. 3.x의 float division을 위한 준비로 보임.

floor 에 대한 의미를 더 알고 싶다면 floor function 참고.


2.x 에서는 기본적으로 차이가 없으나, from __future__ import division 를  안쓸 때의 이야기. 그렇지만 2.5까지 __future__를 쓸 수 있음.

/ 는 'classic' division 이지만, from __future__ import division 를 쓰면 3.x 처럼 float를 반환

3.x 에서는
  • / 는  float 를 반환하고,
  • //는 2.x 처럼 소수를 버린 int를 반환한다.