Dockerfiles and Go microservices. What layout ?

<p>Guys how to organize files layout when you designing small containered ecosystem. Let&#39;s say few applications in different containers communicating via ipc. How this cooperate with this go-layout pattern: <a href="https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2" rel="nofollow">https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2</a> ? What&#39;s the best practice ? </p> <hr/>**评论：**<br/><br/>johandry_amador: <pre><p>This is a structure I use and post recently on gophers.slack.com#grpc</p> <pre><code>├── LICENSE ├── Makefile ├── README.md ├── ${scv}pb │ ├── Makefile │ ├── ${scv}.pb.go │ ├── ${scv}.pb.gw.go │ ├── ${scv}.proto │ ├── ${scv}.swagger.json │ └── swagger.go ├── bin │ └── ${project} ├── cmd │ ├── root.go │ ├── root_test.go │ ├── serve.go │ ├── version.go │ └── version_test.go ├── examples │ └── docker-compose │ ├── data │ │ └── shared │ │ └── README.md │ ├── docker-compose.yaml │ └── env │ └── common.env ├── images │ ├── alpine │ │ └── Dockerfile │ └── scratch │ └── Dockerfile ├── main.go ├── server │ └── server.go ├── vendor │ └── * └── version ├── latest.go ├── version.go └── version_test.go </code></pre> <p>bin/* is ignored on the <code>.gitignore</code> file. </p></pre>macpla: <pre><p>I like it. Few question though. 1. What was a general reaction from #grpc ? 2. This is layout only for server ? how about the client, cause they have to have the same proto file isn&#39;t it ? 3. why main.go is in a project root dir ? 4. why you have different dir for server and different for cmd ? 5. This entire structure is normally under your $(GOPATH)/src/$(repo_host)/$(your_acc)/$(prj) directory tree ? or those things are not compatible with a &#34;go get&#34; idiom ? </p></pre>ChristophBerger: <pre><p>I think there is a definite split of concerns here:</p> <ul> <li>Go source layout -&gt; relevant to the resulting binary only.</li> <li>Dockerfile/docker-compose file/Kubernetes/etc -&gt; relevant to containerization and deployment.</li> </ul> <p>(And as a side note, the file layout proposed in the Medium post <a href="https://www.reddit.com/r/golang/comments/6zih3o/go_project_layout_for_new_go_devs/" rel="nofollow">received some criticism</a>, e.g. for proposing an empty /pkg package just for holding subpackages, which is a red flag to some people.)</p></pre>kylequest: <pre><p>It was just an opinion and it wasn&#39;t backed by any evidence or references.</p> <p>The empty /pkg directory is just placeholder in the repo. If you have no (public) libraries then delete it. If you have libraries put them there. This is exactly what Kubernetes does ( <a href="https://github.com/kubernetes/kubernetes/tree/master/pkg" rel="nofollow">https://github.com/kubernetes/kubernetes/tree/master/pkg</a> ) and that&#39;s one of the most popular Go projects.</p></pre>ChristophBerger: <pre><p>Re-reading my previous comment it becomes obvious to me that it sounds like direct criticism. That&#39;s definitely not what I intended.</p> <p>I am not against empty packages as part of the import path. I only observed that this is a controversial topic and wanted to make the OP aware of that. </p></pre>kylequest: <pre><p>Do you have specific IPC in mind? What kind of container environment are you using? Are you more interested in structuring the Dockerfile file? What kind of config model do you intend to use?</p> <p>A more opinionated go-project-template will be available soon to provide reference implementation for some of the things you are looking for. There are nor hard standards or well established patterns, so what works for some isn&#39;t great for others.</p></pre>macpla: <pre><p>&#34;what kind of container environment are you using&#34; -- what do you mean by that ? I am having such setup. I have web server in go which is not yet sure where exactly will be, and go clients on different platforms. Those client&#39;s has to communicate with other local services (different languages) as well as with remote server. So client is kind of broker. No IPC communication is currently implemented on any node. I was thinking of gRPC as a medium. The point is that I am trying to break huge monolith to have more configurable system. </p></pre>PaluMacil: <pre><p>I think gRPC could be great. My team has fairly junior members, so we stick to simple rest calls.</p></pre>macpla: <pre><p>Well that&#39;s one of mine concerns actually. The more I read and learn about gRPC it looks like a PERFECT solution for almost all IPC communications between services which communicate by requests/commands. It is probably my personal trait but whenever I find something &#34;perfect&#34; a huge red bulb is lighting up on the back of my head :). So I keep digging </p></pre>kylequest: <pre><p>&#34;container environment&#34;: are you using or thinking about using Kubernetes, ECS, Nomad, docker-compose or something else?</p></pre>macpla: <pre><p>only docker-compose for this project. Point is that here everything has to run in a private network within the designed system. It may change in future but now &#34;this is what it is&#34;. Currently docker-compose is a convenient for me, because I can simply deliver entire infrastructure to my no-software team-members. In future clients will rather be hosted on native platforms (and again this is what i love in Go it&#39;s out of the box cross-compilation ability:))</p></pre>