Go


아무래도 파이썬은 속도에 대한 부담감이 있고, C/C++ 은 진짜 이 언어를 100% 써야만 하는 상황 아니면 사용 안하려고 하기 때문에 Go 언어를 배워서 스칼라,파이썬등의 언어와 잘 버무려서 써 보아야겠다.

먼저 InfluxDB 에 로그파일로 부터의 대량의 데이터 넣는 것 부터 ~
레퍼런스는 이거 참고하면 될 거 같고 http://pyrasis.com/go.html

설치하러 고고씽~


저작자 표시 비영리 동일 조건 변경 허락
신고

'Go' 카테고리의 다른 글

Go 언어 시작합니다.  (0) 2017.07.19
Posted by [前草] 이승현 (wowlsh93@gmail.com)
TAG Go 시작


docker vs vagrant vs virtualenv 


도커도 안쓰고 virtualenv도 안쓰고 잘 지내 왔다. 사실 지금도 굳이 도커나 virtualenv를 써서 괜한 복잡도를 올릴 필요는 없는 상황이긴 하지만, (현재는 virtualbox 같은 이미지레벨도 아닌, os 자체를 클론질라로 이미지 떠서 관리하고 있다)  앞으로 둘 중 하나를 반드시 써야할 상황은 올것이다. (분산 텐서플로우를 사용한다던지.. 도커안에 virtualenv 를 사용 할 수도)


참고로 virtualenv 를 가상환경이라고 다들 말해서 , 먼가 거창해보이지만 그냥 유저독립적 python 환경일뿐이다. 따라서 virtualenv 를 윈도우즈,우분투등에서 사용하다보면 OS의 다름 때문에 먼가 잘 안될 때도 있는거 같다. 그 경우에는 레벨이 한단계 아래인 도커가 나을것이며, 도커보다 더 한 단계 아래의 작업 (OS 부팅시 자동로그인되며,브라우저들이 자동으로 뜨고, 각종 서비스들이 시작되는등) 을 하고 싶다면 나처럼...OS 를 굽는수 밖에..


여튼 기타 자세한 사항등은 나중에 정말 필요 할 때 찾아보는 것으로 하고 간략 정리+번역1개 하고 마무리~:-)


참고로 도커로 Pycharm 사용하는것에 관한 글은 아래를 참고 

 

PyCharm + Docker로 파이썬 개발환경 셋업하기 



짧은 정의 

docker

- 리눅스의 컨테이너 기반의 가상화 플랫폼 
컨터이너의 스타트업 시간은 겨우 몇초
- 각각의 내용을 포함한 이미지를 가지고, 그 이미지를 실행함 

vagrant 

-  OS 기반의 가상화 플랫폼 (리눅스,윈도우등) 
- 기존 VirtualBox 등을 통한 가상화를 좀 더 편하게 해주기 위함. 
- 도커보다 무겁다. (스타트업 시간 몇분) 

virtualenv

- 초간단 (하지만 아무것도 안하는거보단 복잡 ㅎ) 
- 독립 파이썬 인터프리터/라이브러리 환경 (라이브러리 설치시 독립적으로 관리된다) 
- OS 독립이 아니다. 즉 우분투에서 만든 virtualenv 환경이 윈도우에서 잘 안될 수도. 
- 윈도우 기반의 virtualenv 에서는 pycrypto 같은거 설치하기 어려움
- 당연하게도 파이썬 코드,파이썬 패키지,모듈 이외의 프로그램 (DB,미들웨어등) 에 필요한 요소들에 대해선 따로   먼갈 해줘야한다. 그냥 Docker 쓰면 되는데..

Docker vs Vagrant 



Vagrant와 Docker가 경쟁자로 보일지라도, 진취적인 관리자들은 서로를 보완하기 위해 함께 사용하는 방법을 발견했다. 이러한 시나리오에서는 Vagrant를 사용하여 기본 VM을 만들고 이 기본 VM을 모두 사용하는 다른 구성을 만들어야 할 때 Docker를 사용하여 다양한 경량 버전을 준비하고 만들며 당연하게 이 두개의 구성위에 virtualenv 를 통해 독립적인 파이썬 환경을 만들 수도 있겠다.


Docker vs Virtualenv

위에 간략정리에서 봤다시피 이 두개의 요소도 노는물이 다르다. 즉 경쟁상대가 아니다. 
그냥 전반적인 개발환경을 도커로 만들어두고, 내부에 파이썬 프로젝트가 하나만 있으면 virtualenv 사용하지 말고, 내부 프로젝트가 늘어날 예정이거나, 여러가지면 virtualenv 를 사용한다. 



virtualenv 는 살아있다 ! [Foot번역] 


https://hynek.me/articles/virtualenv-lives/


PyPI를 통해 패키지를 설치 할 수 있도록 Python을 설치하는 것은 짜증나고 시간이 오래 걸릴 수 있다. 더 나쁜 것은 OS가 숨겨진 오류 메시지를 던지기 시작하는 것인데  특히 데스크톱은 그 경향이 있으며, reddit에서 들어보았을지 모를 어떤 반짝거리는 패키지를 설치하여 서버의 전체 툴 체인을 무너 뜨리는 것도 가능하다.

virtualenv 너머의 글로벌 site-packages 에는 아무것도 설치하지 마십시오.

혹시 님에게는 봉창두드리는 소리?  웬만하면 따르시구요. 적당히 하세요. 

virtualenv in 2014 

virtualenv는 얼마 동안 Python 소프트웨어를 설치하기 위해 받아 들여졌던 표준이었지만 슬프게도, 현재는 몇몇 선교사들이 대담하게 virtualenv의 끝을 선포하고 있다. 일반적으로 컨테이너, 한마디로 Docker 때문에..

나는 그것이 불행하고 근시안적인 것이라고 생각하며 솔직히, 그들은 전체 그림을 보지 못한다 : virtualenv의 임무는 프로젝트를 서로 분리하는 것이 아니라 그것의 임무는 운영체제의 Python 설치와 설치된 패키지와 섞여지지 않게  당신의 것을 분리시키는 것이다. (역주: 비슷한데? ) 
이제 아주 유명한 virtualenv-killer 인  Docker를 사용하여 이것이 왜 좋은 아이디어인지 살펴 보겠다. 이를 위해 python-pip를 신뢰할 수 있는 컨테이너 1에 설치 한 후 얻을 수있는 사전 설치된 패키지를 살펴 보겠다



argparse (1.2.1) chardet (2.0.1) colorama (0.2.5) html5lib (0.999) pip (1.5.4) requests (2.2.1) setuptools (3.3) six (1.5.2) urllib3 (1.7.1) wsgiref (0.1.2)

Surprised? 

새로운 requests , html5lib 또는 colorama를 설치하면 어떻게 됩니까?
나는 당신에게 말하고 싶은것은 :  먼가가 망가지기 시작하고 있으니 정신차리세요.

이러한 일은 언제든지 발생할 수 있으며 시스템을 허약하게 만들 수 있다. 모든 기능을 갖춘 우분투 서버는 당연히 더 많은 물건을 운반하며 파이썬으로 작성된 시스템 툴을 설치할 때마다 어떤 알 수 없는 종류의 파손이 일어날 수 있다. 데비안 패키지 개발자는 pip이 어떻게 작동하고 패치 할 것인지에 대해 마음에 들지 않는다고 결정할 때마다 "폭발 할 것인가?"라는 추첨의 일부로 무의식적으로 참여하게 된다.

OS X 도 전혀 다르지 않다. 그것은 수십 개의 Python 패키지와 함께 제공된다.
데스크탑에서도 - 플랫폼에 상관없이! - 상황이 더욱 열악하다. 보통의 사이트 패키지가 혼란스러우며 대부분의 사용자는 특정 패키지가 왜 설치되어 있는지 알지 못 하고 있다. 튜토리얼 멘토가 확인하는대로 설치 전체를 중단하는 단계는 매우 짧습니다.

운영체제 Python의 site-packages3는 운영체제에 속합니다.

나는 오랫동안 OS 벤더가 다른 곳에서 자신의 물건에 대한 가상 환경을 생성하고 사용자가 시스템 사이트 패키지를 갖도록 한다면 더 좋아할 것이라고 말하고있다. 그러나 그것은 일어나지 않으며  아무도 알지 못하는 일부 시스템 도구가 프로젝트 요구 사항과 호환되지 않는 버전의 라이브러리를 설치하지 않는다고 보장 할 수는 없다.

해당 OS의 버전 명시적으로 작성된 소프트웨어만 site-packages 에  넣어라. 즉, OS에서 제공하는 Python 패키지만 사용하는 시스템 도구이다. 다른 모든 것을 virtualenv에 보관하라. 

virtualenv 대 시스템 격리(도커) 에 대해 논의하는 것을 그만 두십시오. 한 번에 두 가지를 모두 사용해야하고 다른 한 가지로 대체 해서는 안됩니다.

1. Docker / lxc / jails / zones / kvm / VMware / ...를 사용하여 응용 프로그램 당 하나의 컨테이너 / VM으로 응용 프로그램 서버의 OS를 호스트에서 격리하라.

2. 하지만 그들 내부는 시스템  site-packages로 되있으므로  virtualenv를 사용하여 파이썬 환경을 격리시켜라.





http://www.markbetz.net/2014/01/17/python-if-you-have-docker-do-you-need-virtualenv/

https://www.theodo.fr/blog/2015/04/docker-and-virtualenv-a-clean-way-to-locally-install-python-dependencies-with-pip-in-docker/

https://www.quora.com/Is-there-any-advantage-of-running-Tensorflow-in-a-docker-container-rather-than-just-pip-installing-it

https://stackoverflow.com/questions/40177240/what-is-the-difference-between-vagrant-docker-virtualenv-or-just-a-virtual-mac

https://readme.skplanet.com/?p=13470

저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by [前草] 이승현 (wowlsh93@gmail.com)



1.  디렉토리를 상대경로로 정해버림 (즉 JSON 파일 접근할때 그냥 aaa.json 이렇게 접근) 

문제점 : run 을 다른디렉토리에서 실행시키면 (예를들어 /etc/init.d ) 경로를 못찾아서 에러 

덕분에 addJob 만 되고 getJob 이 안되서 무슨 동시성문제가 생겼는지 오해함 

해결 : 절대경로를 찾아서 매칭해줌 ]

szRealPath = os.path.realpath(__file__)
szPaths = szRealPath[:szRealPath.find("gateway_configuration")] + "gateway_configuration.json"

추가: 테스트 시스템을 만들자. 꼭~


2. 직접만든 event 동기화 

문제점: 락이 걸림

해결 : import Queue  


3. SASConfig.xml 파일의 influxdb 위치를 localhost 가 기본으로 해놓자. 

4. Queue 사용시 멀티쓰레드와 멀티프로세스 구분

해결 : 멀티쓰레드 큐는 import Queue  멀티프로세스는 from multiprocess import Queue


저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by [前草] 이승현 (wowlsh93@gmail.com)

티스토리 툴바