Qualcosa di sbagliato nell'avere pseudonimi su un server di produzione?

Question

Qualcosa di sbagliato nell'avere pseudonimi su un server di produzione?

#1 da (11 voti)
#2 da (4 voti)

6

Sul mio server locale, creo alias come questi per velocizzare il mio lavoro:

alias bashrc='vi ~/.bashrc;source ~/.bashrc;echo bashrc has been sourced'
alias bashprofile='vi ~/.bash_profile;source ~/.bash_profile;echo bash profile has been sourced'
alias aliases="clear;cat ~/.bash_profile|grep --color \"alias\""
alias home='cd;ls;pwd'
alias root='cd /;ls;pwd'
alias desktop='cd ~/Desktop;ls;pwd'
alias f='cd ..;ls;pwd'
alias ff='cd ../..;ls;pwd'
alias fff='cd ../../..;ls;pwd'
alias ffff='cd ../../../..;ls;pwd'
alias pa='vim /Users/nav/workspace/someproject/src/main/resources/application.properties'
alias sql="mysql -uSomeDB -p"
alias updatedb='sudo /usr/libexec/locate.updatedb'
alias node1='ssh -i ~/.ssh/somepem.pem [email protected]'
alias datanode='ssh [email protected]'
alias zoostart='/Users/nav/prog/zookeeper-3.4.8/bin/./zkServer.sh start'
alias zoostop='/Users/nav/prog/zookeeper-3.4.8/bin/./zkServer.sh stop'
alias zoocli='/Users/nav/prog/zookeeper-3.4.8/bin/./zkCli.sh'

Queste scorciatoie mi permettono di lavorare più velocemente, dato che non devo ricordare lunghe righe e alcuni di questi alias sono lunghi solo uno o due caratteri, quindi non devo digitare neanche una parola, quindi ho usato un po ' di loro anche sul server di produzione, e questo è un server che usano anche gli altri sviluppatori. Queste scorciatoie possono essere utilizzate anche da loro, dato che svolgono praticamente lo stesso lavoro.

Il mio supervisore differisce e dice che non si dovrebbero mai avere alias definiti dall'utente su un server di produzione. Dice che è sbagliato da parte mia "usare il server come giocattolo".

C'era una istanza che ricordo (in una società precedente in cui nessuno aveva problemi con gli alias) quando creavo alias su bashrc e non eravamo in grado di accedere a un server tramite ssh, ma la soluzione era quella di mantenere gli alias in bash_profile anziché in bashrc. A parte questo, non vedo perché non si dovrebbero usare alias su un server di produzione a patto che gli altri sviluppatori siano informati degli alias. Cosa ne pensa la comunità di questo?

server-side bash production ubuntu

posta Nav 13.04.2017 - 10:44

fonte

2 risposte

4

What does the community feel about this?

Quanto è rilevante? Alcuni ti diranno di farlo, alcuni ti diranno di non farlo. Il tuo supervisore ha deciso di non farlo? ... quindi ascolta il tuo supervisore. Non sei d'accordo con il tuo supervisore? ... quindi prova a fornire buoni argomenti su come ciò sia vantaggioso per tutti.

Ma ecco come ho letto la tua domanda:

I did something good. Why don't you people see the light and agree it's a good thing? You don't agree it's a good thing? Well boo hoo... I'll ask what the community feels about this.

Hai causato un problema usando alias e il tuo supervisore ha preso nota e ora non vuole che tu lo faccia più. Questa è una risposta naturale. Proteggere il server di produzione è più importante di quanto tu possa lavorare più velocemente di pochi secondi.

C'è anche un problema con gli alias. Le persone tendono a ricordare l'alias e dimenticano i comandi che stanno dietro. Installa un nuovo server e ora devi aggiungere gli alias affinché le persone possano lavorare allo stesso modo.

Non ho intenzione di dirti che è buono o cattivo. Devi parlare con tutti per vedere se possono usarli anche tu, quali sono i vantaggi e gli svantaggi. Quindi decidere insieme. Qualunque cosa tu decida, devi accettare (anche se non sei d'accordo con il resto della squadra).

C'è anche un compromesso: invece degli alias basta installare uno script che prende parametri e fa lo stesso (qualcosa come prodScript zoostart , prodScript editprops , ecc.). È quindi possibile mantenerlo nel controllo del codice sorgente, renderlo parte della distribuzione, dell'installazione del server, delle versioni della cronologia, è possibile aggiungere un parametro prodScript help che spiega ciascun comando, ecc. La gente dimenticherà ancora i comandi dietro i parametri ma avrai solo una fonte di verità se devono cercarli, invece di cercare in bash_profile , bashrc , o qualsiasi altra cosa.

Solo i miei 2 centesimi.

risposta data 13.04.2017 - 12:49

fonte

Leggi altre domande sui tag server-side bash production ubuntu

Un evento C # deve avere un tipo di oggetto come primo parametro? Quando si prova è OK usare un metodo del soggetto per testare un altro metodo del soggetto?

score 11 · Accepted Answer

In generale, è consigliabile creare attività comuni di scripting per prevenire errori e lavorare più velocemente. Sono d'accordo con la tua intenzione.

Ma sono scioccato dal fatto che tu sia stato in grado di apportare tali modifiche in primo luogo su un sistema di produzione . A quanto pare hai fatto questi cambiamenti senza prima parlare con la tua squadra. Non sembra una cultura di amministrazione professionale. Idealmente, hai una procedura scritta o basata su script per configurare e distribuire quel server. O i tuoi adattamenti fanno parte di quella procedura e sono controllati da altri membri del team, oppure le tue modifiche hanno introdotto rischi non necessari .

Recenti esempi di alto profilo di piccoli errori da parte di un singolo dev che ha abbattuto l'intero sistema di produzione includono la interruzione di Amazon AWS S3 (causato da un errore di battitura durante l'utilizzo di uno strumento di amministrazione interno) o Interruzione del database GitLab (dove un elemento di sviluppo ha eliminato il database, ma ha confuso un sistema di test con il sistema di produzione). Consiglio vivamente di leggere l'analisi post-mortem di GitLab. Il fatto che sei riuscito a interrompere il tuo login SSH è già abbastanza grave e merita completamente la reazione del supervisore.

Invece di definire i tuoi alias, configura un repository di script di amministrazione che tutti i membri del tuo team utilizzano. A differenza dei tuoi alias, questi script possono essere controllati, testati, documentati, revisionati e controllati. Qualsiasi conoscenza che codifichi in questi script giova anche ai membri del tuo team. Ciò evita anche che i problemi dei tuoi alias non siano aggiornati, ad es. Vedo che hai vari percorsi e numeri di versione hardcoded.

Aneddoto personale: una volta avevo un collega con molti alias di shell. Guardarli lavorare sulla console era magico . Ma quando se ne sono andati e ho dovuto passare attraverso la loro storia di bash per capire come hanno configurato un server particolare, ho avuto difficoltà a seguirlo. Ovviamente gli alias non erano il problema: noi come team non ritenevamo sufficiente la documentazione e lo scripting. Ma quando scrivi tutto ciò che fai in modo che altri possano fare lo stesso, i tuoi alias personali non li aiuteranno.