smartango

I wrote some kind of report about ReacJS day – Verona, October, 5th. But my pc blocked (TODO: buy a new pc, once I understand which), I did not saved the document. I taked a screenshot.

My experiment on React.context will focus on edit state of a page. Currently the page is made of various components and some are switchable to edit-mode and view-mode. I want to add constraint that only one element in a page is on edit mode, and also to add the behavior of switch-to-view-mode-on-ESC-key.

I should provide a value via EditState.provider : elementid

For this I need that every editable element have a unique id in the page.

Some faced it in https://github.com/facebook/react/issues/1137, the most immediate and simple proposed solution is
https://github.com/facebook/react/issues/1137#issuecomment-95699269

But I will skip this problem passing a register function

const EditStateContext = React.createContext( {
   editElement: null,
   register: () => {}, // return an unique id
   editModeOn: (id) => {}, // toggle on
   editModeOff: (id) => {} // toggle off
})

as documented the value should be the state of a containing component

import { EditStateContext } from './EditStateContext';
class App extends React.Component {
  constructor(props) {
    super(props);
    this.editableComponents = [];
    this.register = () => {
	let newLength = this.editableComponents.push(this.editableComponents.length);
	return newLength - 1; // this is enough to stay safe on race condition
    }
    this.editModeOn = (id) => {this.setState({editElement:id})}
    this.editModeOff = (id) => {this.setState((oldState) => { if (oldState.editElement ===id) {return {editElement:id} }} )}
    this.state = {
	// about js lang I dislike the use of -1 for notFound of indexOf, but ...
	editElement: -1,
	register: this.register,
	editModeOn: this.editModeOn,
	editModeOff: this.editModeOff
    }
  }
  componentDidMount() {
	document.addEventListener('onkeyup',(e) => {
		if (e.code === 'ESC') { // Replace with something meaninful
			this.setState(state=>{ return {editElement: -1 }} ));
		}
	});
  }
  render() {
	return (
		<EditStateContext.Provider value={this.state}>
		  <Content />
		</EditStateContext.Provider>
	);
  }
}

The consumer will receive the value

import { EditStateContext } from './EditStateContext';

function withSkipEditableEl(Element) {
   return (
	<EditStateContext.Consumer>
		{ (props) => (<Element ...props />) }
	</EditStateContext.Consumer>
   )
}

Now I can use that HOC function passing the editable element.

It may works, I will test tomorrow.

I am still confused about contexxt and a number of pending tasks on the go.

Running a docker container from inside a docker container, I mean.

Of course one can define an image that instanciate a container as its default command, and this would lead to an infinite loop of forks … let’s see

The infinite containment

docker run -v /var/run/docker.sock:/var/run/docker.sock -name whocare alwaysfork

Ok, that is bad and I will not describe.

Container near a container

Maybe it is a bad thing, but most of the time docker and container is used interchangely, so I would had better written docker near a docker, that is cool.

What is near and why not “in”? it is like the infinite containment example, it is near because every contained execution is managed by the main daemon (dockerd) running in the host machine.

In fact in a infiniete containement you are not forking endless, but you are asking the dockerd to instanciate endlessly a new container, there is nothing that make one of the container a manager of the other, or a more authoritative manager than the other: every container that can access the /var/run/docker.sock socket and has the right can stop/remove every container in the machine.

Security concerns

I am not expert of security concerns, but everytime you do something “strange” there are great chances that that “strangeness” could lead to a security hole. (not being an expert I think even “not-strange” done by me can imply bad things)

Here the problem is due to the way docker is managing user, and mostly by how it manage the uid=0, root. The command by itself run the image standard command, and it is expected that the Dockerfile specify USER that will run the default command (and that is something != root).

But the weird part here is that being actually a container-near-container situation, at every instanciate point it could be switched to root with a

docker exec -u root -it myfunnyimage ./abadcommandforyou

this could be run from any container, call it aquitecontainer, all that is needed is the docker command in the image of aquitecontainer and that the socket is mounted as -v /var/run/docker.sock:/var/run/docker.sock and … so?

So you can switch to root from a container not running as root, because you can see the socket, and this is enough.

Two case are given:

1. the containing container is running as root, so no particular needs to access the socket
2. the containing container is running as a unprivileged user, but it has access to socket, so no particular needs to access the socket from the anyuserisused inside
3. the containing container is instanciated by root, but running as unprivileged user, that again map to the calling user, that is root

Yes, the problem here is that docker daemon always map the “no-root” user to the uid of the user that call its api.

But really it is not enough

In fact to access /var/run/docker.sock a user must be part of docker group, when a container is instanciated with its default user the groups are not migrated, so the image’s definition of user’s group membership is something to take into account: if internal user of the docker has no access to the docker.sock it can not communicate with the dockerd running, so no more docker in docker, no more root migration

I need some moment to fully understand this:

const compose = ( ...fns ) => fns.reduce( ( f, g ) => ( ...args ) => f( g( ...args ) ) );

reduce method is trickly: when initialValue is not given, the first element of the array is taken as first argument of reduce’s callback parameter, so f is the first argument, g is the second, (…args) is the formal parameters (passed to the resulting function), at the end of the reduction all …fns are applyied in reverse order (i.e. compose(f,g,h) g is applyed before f, and h is applyed before g, resulting in (…args) => f(g(h(…args)) ).

But once I got it it happen to be really an elegant way to write it:

const $d = $data.mergeMap( compose(Rx.Observable.from, r=>r.split('\n')) );

and not:

const $d = $data.mergeMap(r=>Rx.Observable.from(r.split('\n')));

that is less readable

Probabilmente in ritardo col resto del mondo, h chiarito un punto importante riguardo gli observable, e l’ho capita usando observable-redux. Prendo nota.

Definendo un Epic, da uno stream di action$ si restituisce un’altro stream di action

La Epic è eseguita dopo che il relativo reducer ha fatto il suo lavoro.

È possibile, data una action, restituirne un’altra, tramite .map()
in tal caso l’oggetto da restituire è proprio una action

È possibile inoltre restituire uno stream (un observable) che restituisce una (o più) action, in questo caso
si deve usare il metodo mergeMap()

Es.:

const loadOrdersEpic = (action$, store) => {
  return action$
  .ofType('LOADORDERS')
  .flatMap( () => { Observable.from(ajax('req')) })
  .mergeMap((res) => {
    return Observable.merge(
      Observable.of({type:'SUCCESSFULL.NET'}),
      Observable.of({type:'DATAREADY', res})
      );
    });
}

a differenza di map posso comporre degli observable(s) quindi generare più action (ovvero uno stream che genera più action)

const loadOrdersEpic = (action$, store) => {
  return action$
  .ofType('LOADORDERS')
  .flatMap( () => { Observable.from(ajax('req')) })
  .map((res) => {
    return {type:'DATAREADY', res}
   });
}

Coso ho imparato oggi

(professore FONTECEDRO https://www.youtube.com/watch?v=aqTmhBca7f8 )

Dopo aver insistito col farmi dare un server da poter usare per metterci redmine e gogs, mi sono ritrovato oggi a dover far girare i due docker insieme e farli interagire.

C’è da dire che di docker non ci capisco nulla, quindi oggi ho imparato ad usare quello che mi serve di docker.

Prima di tutto sono container, ovvero sono basati sull’esecuzione di un processo bindato (perché dire bendato non da abbastanza l’idea) rispetto al resto del sistema. In sostanza quasi una macchina virtuale, ma gira sullo stesso kernel dell’os nel quale lo si lancia, è basato su concetto di cgroups di linux, e siccome non lo so rimando a https://en.wikipedia.org/wiki/Cgroups

Quello che interessava a me era di tirar su una immagine docker di redmine e una di gogs e farle girare nel server, e in più collegare i due container integrare un sistema per il controllo del progetto che desse delle statistiche aggiornate della situazione.

Ecco, quest’ultima parte è particolarmente complicata se non sai niente di docker.

*Come si fa girare un docker.*

Sostastanzialmente ho capito che per far girare un docker devi prima prendere l’immagine e poi avviarlo. Inizialmente avevo inteso che bastasse riferirsi alla immagine e scrivere

docker run image/name [altrivari parametri]

e così esso faceva tutto. Ho poi scoperto che questa è una visione un po’ miope. In effetti mi sono trovato con immagini nelle quali era già definito lo script di start. In generale al comando “docker run” si specifica il nome dell’immagine (che docker scarica in una qualche maniera da un repository delle immagini) e il comando da eseguire all’interno del container contestualmente creato al momento in cui viene eseguito run. Frase contorta, disgustorama, come direbbe il professor Fontecedro. Ma in realtà il comando

$ docker run -d -p 80:80 my_image nginx -g ‘daemon off;’
60baacd90721 # valore restituito

carica l’immagine my_image, crea un container, e, all’interno di quello esegue il comando “nginx -g ‘daemon off;'”.
Ora, visto che si tratta di una immagine personale, evidentemente devi essere a conoscenza che contiene il programma nginx, e quindi lo puoi eseguire. In generale io ho immagini nelle quali è definito all’interno dello script start.sh l’avvio di un server.

Ecco esattamente quello è il concetto di immagine: cosa c’è dentro il microservice che viene eseguito tramite docker.

Importante è anche il concetto di container: l’esecuzione della immagine con i relativi parametri di esecuzione.

Così, mi pare di aver capito, che se eseguo “docker run” con tutti i parametri del caso, ottengo un container id, è una chiave unica, sembra sha256, che identifica il container. A quel punto posso fermarla o riavviarla alla bisogna. Così:

docker stop 60baacd90721
docker start 60baacd90721

e 60baacd90721 è l’id del container che viene restuito dal comando “docker run”

Ho poi capito che se ho bisogno di entrare nella “quasi-macchina-virtuale” posso eseguire un comando a piacere in un virtual terminal di quella macchina, così

docker exec -ti 60baacd90721 bash

e posso specificare l’utente col quale eseguirlo

docker exec -u redmine -ti 60baacd90721 bash

perché avevo il problema di dover controllare il risultato del comando “git ls-remote -h ssh://…” per controllare l’accessibilità all’altro container.

A proposito del far girare più container sulla stessa macchina, il problema è stato farli communicare tra loro (magari con una sola m). E per questo c’è

docker network

sembra che docker sia un’insieme di sotto programmi, un po’ come è git. Quindi

docker network ls

elenca le reti definite nel sistema.

docker network inspect [networkname]

mostra la definizione della rete

docker network connect [networkname] [containerid]

connette una rete al container. E questa cosa è magica. In pratica se 2 container non riescono a vedersi è perché, generalmente, sono stati definiti tramite il comando run o tramite docker-compose. Nel primo caso il container avrà associata la rete “bridge” di default, nel secondo caso viene creata una rete on-the-fly da docker (c’è da controllare cosa sia docker-compose, il comando, per capire perché), e il suo nome è dato dal nome della definizione col postfisso “_default” (cioè se docker-compose.yaml è nella cartella “sfortuna” al momento della esecuzione di docker-compose, la rete creata si chiamerà sfortuna_default), nel mio caso si chiamava bugs:

$ sudo docker network ls
NETWORK ID NAME DRIVER SCOPE
e0af7dce8070 bridge bridge local
ac43047ffe4f bugs_default bridge local
e117f156b39d host host local
b2a366b4b71a none null local

host è un tipo particolare di network, consiste nel risiedere nella stessa interfaccia del server dove gira … posso solo immaginare i casini nella gestione, ma è più veloce, evidentemente, perché non è emulata.

Ora, quello che ho trovato veramente fantistico oggi (eh, ma ho sudato parecchio per arrivarci) è proprio

docker network connect [netname] [containerid]

e

docker network disconnect [netname] [containerid]

in pratica si opera su un container esistente, e in esecuzione, e gli si aggiunge una scheda di rete virtuale, e la si toglie.

Cosmico.

È così che il container di redmine può vedere la rete del container gogs, e può richiedere cose tipo

git ls-remote -h ssh://git@172.17.0.2:10022/danieldock/privatetest.git

Ovviamente il viaggio di oggi è stato infarcito di “boh … non funziona, lascio stare .. ma…” e dal leggere cose tipo “I’ll merge if it is the case” https://github.com/dergachev/redmine_git_remote/issues/34 (no, che dici, quanti devono ancora scoronare?)

Ok. Tutto funziona e abbiamo un sistema per monitorare l’andamento dello sviluppo delle features, la gestione delle anomalie, vediamo chi sta lavorando a cosa e come, eccetera.

Era ora.