ubuntu 14:04 도커를 사용 중에 deb.debian.org 연결에 실패한다.

 

# apt-get update
Ign http://deb.debian.org jessie InRelease
Hit http://security.debian.org jessie/updates InRelease
Get:1 http://deb.debian.org jessie-updates InRelease [7340 B]
Hit http://deb.debian.org jessie Release.gpg
Hit http://deb.debian.org jessie Release
Get:2 http://security.debian.org jessie/updates/main amd64 Packages [825 kB]
Get:3 http://deb.debian.org jessie/main amd64 Packages [9098 kB]
Fetched 9930 kB in 14s (666 kB/s)
W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/InRelease  Unable to find expected entry 'main/binary-amd64/Packages' in Release file (Wrong sources.list entry or malformed file)

E: Some index files failed to download. They have been ignored, or old ones used instead.

 


이 부분으로 되어 있을 텐데..

 

# cat /etc/apt/sources.list
deb http://deb.debian.org/debian jessie main
deb http://deb.debian.org/debian jessie-updates main
deb http://security.debian.org jessie/updates main


도메인을 변경한다. 

 

 

# vi /etc/apt/sources.list
deb http://archive.debian.org/debian/ jessie main
deb-src http://archive.debian.org/debian/ jessie main
deb http://security.debian.org jessie/updates main
deb-src http://security.debian.org jessie/updates main

 

 


나온지 오래되어서 도메인이 옮겨졌다..


 

 

from ubuntu 14를 사용하는 Dockerfile에는 아래와 같이 한 줄로 작성한다.

 

RUN printf "deb http://archive.debian.org/debian/ jessie main\ndeb-src http://archive.debian.org/debian/ jessie main\ndeb http://security.debian.org jessie/updates main\ndeb-src http://security.debian.org jessie/updates main" > /etc/apt/sources.list
Posted by 김용환 '김용환'

<뽀모도로>

 

1. 어떤 일을 할지 정한다.

2. 뽀모 도로(타이머)를 25분에 맞춘다.

3. 타이머가 끝날 때까지 그 일을 한다.

4. 짧게 쉰다(보통 5분)

5. 매 4회의 ‘뽀모도로마다 길게 쉰다(15~30분).

 

<레거시 시스템>

 

실행 관례의 도입 자체를 관리자나 팀 구성원에게 설득하지 말고 현재 일하는 방식과 비교해 가져올 이익에 집중해야 한다.

빠른 피드백 루프, 요구사항과 비용에 대한 더 나은 이해, 지식 공유, 줄어드는 버그, 전체적으로 자동화되고 릴리즈가 빨라지는 일들이 기술적 실행 관례를 도입함으로써 얻을 수 있는 가치들이다.

 

테스크 코드를 머저 개발하기!! 

 

 

<채용>

 

소프트웨어 장인이 직장을 찾을 때는 특정한 프로젝트나 펜시한 기술, 괜찮은 급여만을 쫓지는 않는다. 소프트웨어 장인은 생산적인 파트너십과 아침에 일어날 때마다 일하러 가는 것이 행복한 직장을 찾는다.

 

<사기>

개발자들의 낮은 사기는 소프트웨어 프로젝트 실패의 주된 이유 중 하나이다.

 

소프트웨어 장인을 팀에 들이는 것은 기술적인 문제 해결에 도움이 될 뿐만 아니라 열정을 불어 넣고

혁신을 일으키는 데 지지자이자 동맹이 되어 준다는 것이다.

 

배움의 문화 만들기

 

--- 아무도 참여하려 하지 않는다면,

모범을 보여라 (TDD)

관심을 보이는 사람들에게 집중하라

강제하지 마라

모두를 변화시켜 들지 말라

모임에 대한 약속을 제때하라

허락을 구하지 마라

투덜대지 마라

리듬을 만들라

 

 

 

 

 

 

 

Posted by 김용환 '김용환'

java.lang.RuntimeException: Missing scala-library.jar    

불러오는 중입니다...

 

build.sbt 파일의 스칼라 버전이 실제로 로컬에 저장되어 있지 않으면. 에러가 난다.

 

즉 build.sbt 파일에는 2.11.11을 적어두고 로컬 머신에 2.11.8이 설치되어 있을 때 .sbt 에러가 발생할 수 있다.

scalaVersion := "2.11.11"

 

 

scalaVersion := "2.11.11"을 scalaVersion := "2.11.8"로 변경하든지 scala 2.11.11로 설치하면 된다.

Posted by 김용환 '김용환'

 

spring boot 2 책을 보면 WebMvcTest DataJpaTest, JsonTest, RestClientTest  등을 설명하는데..

 

이것만 있는 것이 아니다. 

 

여러 개가 더 있다.

 

https://docs.spring.io/spring-boot/docs/current/reference/html/test-auto-configuration.html

 

Appendix D. Test auto-configuration annotations

Appendix D. Test auto-configuration annotations The following table lists the various @…Test annotations that can be used to test slices of your application and the auto-configuration that they import by default: Test sliceImported auto-configuration@DataJ

docs.spring.io

 

@DataJdbcTest

@DataLdapTest

@DataMongoTest

@DataNeo4jTest

@WebFluxTest

@DataRedisTest

@JdbcTest

@JooqTest 등을 포함한다.

 

 

자세한 내용은 다음을 확인한다. 

 

https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-testing.html

 

46. Testing

A Spring Boot application is a Spring ApplicationContext, so nothing very special has to be done to test it beyond what you would normally do with a vanilla Spring context. By default, @SpringBootTest will not start a server. You can use the webEnvironment

docs.spring.io

 

Posted by 김용환 '김용환'

 

소프트 스킬을 읽고 괜찮은 부분을 발췌한다.

 

 

<발췌>

 

1. 새로운 습관 만들기

 

존 레식 (John Resig) 블로그에서는 '코드를 매일 작성하라'라는 제목의 글이 있다.

 

매일 최소 30분씩 코드를 작성하는 습관을 들이기 전에는 부가적으로 진행하는 프로젝트에 아무런 진척이 없었다. 그 게 습관이 되니 생산성에 큰 향상이 있었다고 한다. 

 

https://johnresig.com/blog/write-code-every-day/

 

John Resig - Write Code Every Day

Last fall, work on my coding side projects came to a head: I wasn’t making adequate progress and I couldn’t find a way to get more done without sacrificing my ability to do effective work at Khan Academy. There were a few major problems with how I was work

johnresig.com

 

새로운 습관을 만드는 것은 새로운 반복 행위를 만드는 것과 비슷하다. 긍적적인 습관이 많을 수록 목표로 가는 길은 더 쉬워질 것이다.

 

다음에는 새로운 습관을 위한 신호를 찾아야 한다. 

 

소프트 스킬의 저자는 매일 저녁 30분씩 기술 서적을 읽는 습관을 가졌고 매일 30분씩 걷는 새로운 습관을 개발하기 로 했다.

 

 

 

 

 

 

2. 뽀모도로 기법

 

학자인 푸앵카레는 다음과 같이 말했다.

 

규칙적으로 오전 10시부터 12시까지, 오후 5시부터 7시까지만 일했다.그는 더 일해봐야 얻는 게 거의 없다고 생각했다.

 

 

 

 

<느낌>

 

내 생각과 많이 비슷한 내용이 적혀 있었다.

 

개발 + 안정적인 재정 독립!!!

Posted by 김용환 '김용환'

 

https://perso.limsi.fr/pointal/_media/python:cours:mementopython3-english.pdf

불러오는 중입니다...

 

 

Posted by 김용환 '김용환'

최근에 아는 DBA로부터 들었던 쇼킹한 줄임말


(약자)

최한시 , 최번시



최한시 - busy hour, peak hour, peak busy hour (트래픽이 가장 많은 시간대)

최번시 - idle hour, off-peak hour (트래픽이 가장 적은 시간대)


정보통신기술용어 뿐 아니라 특허, 정책연구원에서 사용하는 단어였다.



한가한 시간, 새벽 작업이라고  했지.


지금까지 개발하면서 한번도 써보지 않은 단어였다..

Posted by 김용환 '김용환'




오늘 트위터 CTO와의 간담회를 마치고 바깥에 나오는데..


점심식사를 같이 하면 좋겠다는 인사팀 수장님이 얘기가 나왔다.





잠깐동안 망설였다.




아.. 내가 트위터 CTO와 밥을!!!   동료와의 점심 식사 약속을 어떻게 하지?


동료와는 다음 주에도 식사할 수 있긴 한데... 어떻게 하지?


으와..










인사팀 수장에게 정중하게 거절하고 동료를 만났다.


(쏘리 트위터 CTO~~)



저녁에 돌아보니.. 나는 미쳤나 보다... 


그런 기회를 놓치다니.. 




그래도 내 동료와 점심 시간 약속을 지켜서.. 그게 참 좋았다. 





Posted by 김용환 '김용환'


kubernetes의 pod의 bash에 접근하려면, 먼저 pod 이름을 알아야 한다.



$ kubectl get pod

NAME                                READY   STATUS    RESTARTS   AGE

jenkins-8498fcb9b5-8k8b8         1/1     Running   0          40m



docker와 비슷하게 pod 이름으로 bash에 접근한다. 


$ kubectl exec -it  jenkins-8498fcb9b5-8k8b8 -- /bin/bash




Posted by 김용환 '김용환'

보통 kubernetes pod을 재시작하려면 deployment 파일을 이용하는 경우가 많지만..


설정 파일 없이 확인하는 방법도 있다.



먼저 도커 이미지 이름을 얻는다.


아래 커맨ㄷ는 실제 컨테이너의 데타 데이터 이름과 컨테이너의 도커 이미지 이름을 얻는 커맨드이다.


$ kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ sort


ingress-nginx-controller-szb9s: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.19.0,

ingress-nginx-controller-ttq2h: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.19.0,

jenkins-8498fcb9b5-6n2vm: jenkins/jenkins:lts,

kube-apiserver-dkosv3-jenkins-master-1: gcr.io/google-containers/hyperkube-amd64:v1.11.5,

kube-apiserver-dkosv3-jenkins-master-2: gcr.io/google-containers/hyperkube-amd64:v1.11.5,

kube-apiserver-dkosv3-jenkins-master-3: gcr.io/google-containers/hyperkube-amd64:v1.11.5,




원하는 것은 바로 아래 커맨드이다. 메타데이터와 컨테이너 이름을 얻을 수 있다.


$ kubectl get pods -o=custom-columns=NAME:.metadata.name,CONTAINERS:.spec.containers[*].name

NAME                                                           CONTAINERS

jenkins-job-8f24e681-5b83-4f87-b713-69c86deedb22-25gsh-vjh9r   jnlp

jenkins-job-914tx-fthwt                                        jnlp

jenkins-8498fcb9b5-6n2vm                                    jenkins

my-release-mysql-65d89bd9c4-txkvn                              my-release-mysql








재시작을 진행한다. reboot 커맨드가 도커 안에 포함되어 있으면 다음처럼 실행한다.


$ kubectl exec jenkins-8498fcb9b5-6n2vm -c jenkins reboot



만약 다음 에러가 난다면, kill 커맨드를 사용해야 한다.


rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "exec: \"reboot\": executable file not found in $PATH"




kubectl exec jenkins-8498fcb9b5-6n2vm -c jenkins  -- /bin/sh -c "kill 1"



Posted by 김용환 '김용환'