Is the site directory in puppet 4.x required - installation

I'm following this site: https://puppet.com/docs/pe/2017.2/r_n_p_full_example.html
In this file path: /etc/puppetlabs/code/environments/production/site/profile/manifests/jenkins/master.pp
Is the directory called 'site' required?
Could the directory called profile above be moved to the modules directory?
I'm using puppetserver version 4.10.12.

Is the directory called 'site' required? Could the directory called profile above be moved to the modules directory?
It depends. In a general sense, sure, you can put your 'role' and 'profile' modules into the environment's modules/ directory. That's where I put mine.
But the writeup you linked explains why it demonstrates using a different directory:
If you deploy your code with Puppet Enterprise’s code manager or r10k,
we recommend putting these two modules in your control repository
instead of declaring them in your Puppetfile. Since code manager and
r10k reserve the modules directory for their own use, you must put
them in a separate directory
If you are not using either of those code deployment tools and don't anticipate doing so any time soon -- like me -- then not only can you put your modules into the modules/ directory, but that's what I would recommend doing. But if you plan on using one of those then do follow the guide in this matter.

Related

How to use an alternate go.mod file for local development?

Currently I am working on an API which uses Serverless Framework with Go.
I'm using the Serverless-offline plugin for local testing.
This API depends on a few other repositories (which I also maintain), which I import using the go.mod file.
However I am having a hard time refining my developer workflow.
Currently, if I want to make changes in a repository which this API depends upon, I have to alter the projects go.mod to include replace directives for the purpose of testing, but then I'm having to manually change it back for deployment to production.
Basically I'm looking for a way to include replace directives, which only get applied during local development. How has everyone else dealt with this problem?
Bonus question: Is there any way to run Serverless offline in docker? I'm finding that serverless-offline running on the bare metal is causing inconsistencies between different developers environments.
You can run go commands with an alternate go.mod file with the -modfile option:
From Build commands:
The -modfile=file.mod flag instructs the go command to read (and
possibly write) an alternate file instead of go.mod in the module root
directory. The file’s name must end with .mod. A file named go.mod
must still be present in order to determine the module root directory,
but it is not accessed. When -modfile is specified, an alternate
go.sum file is also used: its path is derived from the -modfile flag
by trimming the .mod extension and appending .sum.
Create a local.go.mod file with the necessary replace directive for development and build, for example, with:
go build -modfile=local.go.mod ./...

How to use modules replace functionality in cloud functions

I have a google cloud function that is a subdirectory in a repository. It uses the "Directory with source code" option in the settings menu. I keep getting this error on deploy:
Deployment failure:
Build failed: go: parsing /utils/pubsub/go.mod: open /utils/pubsub/go.mod: no such file or directory
go: error loading module requirements
I'm assuming that GCF does not upload the entire directory to the instance, but instead only the folder? This breaks the replace functionality of Go modules. Is there something I am doing wrong?
Link to the repo: https://github.com/FreekingDean/jeffbotgo/tree/5d735cc/slackevent
I work at Google and on this product.
Only the directory where you run gcloud is uploaded. There is no staging step beyond zipping the current directory and uploading it.
Notably, modules are preferred by the builder over vendor. If there is a go.mod, modules will be used. When you upload your function, it only includes the directory with your function at the root, not any directories one level up. So, when there is a go.mod and you have a replace directive pointing one level up, it will not work.
The solution for now with this layout is to vendor and not upload the go.mod/go.sum files. When using gcloud, you can create a .gcloudignore file to do this for you. See https://cloud.google.com/functions/docs/concepts/go-runtime#specifying_dependencies for more detail. Alternatively, modify your project to include any necessary helper packages in subdirectories.
I had the same issue today.
When reading thru the documentation for the 8th time i came across a warning box bellow the "Vendor directory" headline.
Warning: If your project has both a go.mod file and a vendor directory
at the root of your project, the vendor directory will be ignored
during deployment. You must use a .gcloudignore file to ignore the
go.mod file in order to ensure that your vendor directory is used
during deployment.
So basically once i added a .gcloudignore file with go.mod (will add go.sum as well) everything worked. So i guess if you have a go.mod file the cloud function will try to fetch dependencies instead of using the ones uploaded in the vendor folder.
I'm just guessing here tough.

wercker.yml in a subdirectory

having a Bitbucket repository, there is a project in a subdirectory that should be built. I'd like to have the wercker.yml in this subdirectory as well.
I tried to add an environment variable WERCKER_ROOT to the pipeline containing the subdirectory: /here-is-werckerfile, according to wercker devcenter which seemed to have no effect.
Any ideas?
As far as I know you can't change this environment. It's not used by wrecker, it's only meant to provide a read only information in case you need to know where your code is located.
To answer your question: once again as far as I know you can't use a wercker.yml from a subdirectory as there's no way to set it's location for wercker - it'll already search for it in your repository root.
edit however you can change the source dir, as mentioned here: http://old-devcenter.wercker.com/articles/steps/variables.html - with the WERCKER_SOURCE_DIR environment, so you can put your wercker.yml in the repo root but use the sub directory for building.

Path for persisting files between Capistrano deployments in a Ruby app

Where is the proper path for creating files using Ruby on a *nix environment? The files must persist between restarts and releases. Obviously using the project path doesn't work as Capistrano will create a new folder for each push.
Capistrano has a system directory created by default that should be linked to the shared/system directory at the root of your release path. This will persist between deployments.
You should put anything there that is not specific to your deployment, for example, attached files or other user uploads.
In your version control system you should be sure to not deploy this directory as to avoid packaging up your development-specific content. Generally it should be ignored, not included in your version control.

Ruby - Where to put resource files that a module in lib relies on?

I am trying to structure my ruby project following best practices. I currently have something like this:
test_project/
bin/
test_project # My Executable
lib/
test_project/
my_module.rb
test_project.rb # Loads my_module.rb
I setup it up this way based on recommendations I found on the web.
My problem is I have some resource files, "resouce1.txt" and "resouce2.txt". My executable needs to open the file "resource1.txt". my_module.rb needs to be able to open the file "resource2.txt". Where do I put these plan text resource files in this directory structure and how to I open them (File.open) from the corresponding ruby files.
Since /lib has to do with specifically the Ruby that powers your gems, I would put it in a top-level directory in your gem named after their subject matter. If they are files with lists of species I would call it /species.
You could also go the Rails way and put it in an /assets folder if you have a lot of external assets like /assets/species. Either way, I would not be prone to put them in /lib.
I don't think there is a standard place for these, as for the most part it is operating system dependent (/var and /etc vs Program Files vs the Application Bundle). But your best bet (I think) is to either put them in the root of your hierarchy, put them in lib/ or, if they really are static text files, put them in your script.

Resources