当购买了 MindSphere tenant 之后, 会收到一封邮件, 大致内容如下图:
对应的 tenant 名字以自己的为准, 不会是下面的”supplab1”, 而且地址也不是”https://supplab1.cn1.mindsphere-in.cn”.
之后, 便可以通过此 URL 登录 MindSphere, 部署、注册 Cloud Foundry 应用.
成功登录后可以进入 launchpad, 看到当前可以使用的 App:
cf-cli_6.51.0_winx64.zip
(此为解压版, 解压配置了环境变量即可用).
安装 Cloud Foundry Cli(下面操作都是基于前面附件版本的). 当安装 c-cli 过后, 系统默认会将其安装的可执行文件目录加入 Path(解压版需要自行手动配置)
打开 CMD 命令行, 开始使用 Cloud Foundry Cli, 在终端下输入 cf version, 查看是否安装成功
如图所示, 则 Cloud Foundry Cli 安装成功.
访问上图给出的 url “https: //login.cf.cn1.mindsphere-in.cn/passcode”URL 获取一次性 passcode
复制过后, 切换到 CMD, 直接右键进行 paste(密码在 CMD 中不可见), 然后直接回车. 接下来选择自己对应的 org 和 space.
登录成功过后, 选择一个 org, 然后再选择一个 space.之后, 便可进行自己 App 的正常 push.
PS:
若是非 Admin 账户登录, 第一次是看不见任何 org 的, 且无法在自己的 space 里进行创建任何 service instance.若要能看见 org, 请咨询管理员自行获取 OrgManager 权限; 若要创建 service instance, 请获取 SpaceManager 权限.
命令操作及其它角色, 可参考 http://cli.cloudfoundry.org/zh-Hans/cf/
打包 app、编写 manifest.yml, cd 进入到 manifest.yml 目录下(一次可以 push一个 app, 或者多个 app, 所以针对不同的 app 有不同的编写 manifest 的方式, 具体可以参考 Cloud Foundry 官网介绍: https://docs.cloudfoundry.org/devguide/deployapps/manifest.html). 这里做一个简单的单个 app 和多个 app 的 manifest.yml 编写区别:
针对单个 app:
如上图所示, 这里只有一个应用.所以在 applications 这个属性下面, 就只有如上所示的几个属性, 在 name 前面有一个横线”-”, 这个就代表着下一次出现”-”时, 这些属性都是同一组属性, 类似转换为 json 中的.
2. 针对多个 app:
如图所示, 只需在加一个”-”, 然后书写对应的属性, 即可识别为一个新的 app, Cloud Foundry 会自动进行识别.
manifest.yml 及文件目录格式: 针对此应用, 只需要 push1 个 app. 一个 java 应用. 所以 app 的 manifest 文件格式和 push 的目录结构如下:
manifest.yml 文件, 红色标注的是必写的, 未标注的根据项目要求来决定:
由于是两个应用, 所以需要在不同应用是, 用一个”-”进行隔断. name: push 到 Cloud Foundry 里应用的名字, 这个是需要和在 MindSphere 里, 注册 app 填写 components 里的 name 对应的. path: push 时, 需要 push的文件的本地路径, 默认相对路径, 相对于当前 manifest.yml 文件路径. memory: 给 app 分配的内存大小. 这里单位只支持”M”, “MB”, “G”, “GB”, 且只能使用整数, 如 1.5GB 这种写法是不允许的. buildpacks: 这一个请使用 MindSphere 的 Cloud Foundry 提供的 buildpack, 在 cli 命令行里使用 cf buildpacks 可以查看当前提供的 buildpack. random-route: 这一项推荐为每个应用配置为”true”, 这样 Cloud Foundry 会为每个 app 随机生成一个 URL。这样防止后续校验时, 在 Operator Cockpit 里, 自动部署 app 时, 上传 app 创建路由时, 导致生成相同的 URL. disk_quota: app 所占磁盘大小. services: service1Name service2NameNote: 除此之外, 目前还有一个属性 stack: cflinuxfs3. 如果不写的默认就是这个, 用来指定 app 所使用的 stack 信息, 目前最好使用 cflinuxfs3, 因为 cflinuxfs2 可能会导致 app 无法启动. 其余具体配置请参加 Cloud Foundry 官方文档: https: //docs.cloudfoundry.org/devguide/deploy-apps/manifest.html 然后执行命令: cf push
一般应用都需要依赖于服务, 如 mq、postgresql 数据库等等, 查看平台支持服务的命令: cf marketplace
创建服务实例的命令: cf create-service {service} {plans} {servicename} e.g. 创建 postgresql 的实例: cf create-service postgresql94 postgresql-xs backend-postgres.
Note: 若此前在 push 应用时, 已经指定了 services 这一项的话, 那么下面的步骤便无需执行; 只需保证在 push 应用时, 该服务实例已
被创建, 且用 cf services 查询服务时, 红色框标注的要为”create succeeded”或者”update succeeded”状态, 此时才能执行 cf push, 否则应用无法成功绑定 service.
执行 cf services 查看已创建的 service instance
服务和应用绑定命令: cf bind-service {appName} {yourServiceName}
e.g.绑定 postgre 数据库(其实这里可以不用进行绑定, 因为 cf push 的时候, 在 manifest.yml 已经指定了 service, 所以这里 Cloud Foundry 会自动进行绑定).
然后填写自己 app 的信息, 信息填写无误后, 点击右上角的保存(各项具体信息如何配置, 请参见 MindSphere 官方文档: https://developer.mindsphere.io/zh/howto/howto-cf-running-app.html).
点击”授权管理”, 进行 app 权限配置
这里默认会生成以上一步中, app 名称开头的 scope 名字, 所以上一步填写 app internal name 时, 必须根据 app 代码的需要进行起名.
具体操作请参见: https://developer.mindsphere.io/zh/howto/howto-cf-running-app.html
2.2.3. 为 app 生成 app credential
在 Developer Cockpit页面上，点击 Authorization Management 标签，进入如下页面
选择 Read and Write 过后，最终由 Operator 部署过后，分配给 IOT User 后，这个 Operator 便可以访问 IOT User 的数据()。
生成过后请自行保存好，否则该窗口关闭后将无法再看到当前 id 和 secret，只有重新再盛情。通过这个 app credential，也可以在本
地进行快速开发，从而来获取访问 MindSphere 的 token，详情请见：“https://developer.mindsphere.io/zh/howto/howtolocal-development.html#2”.
重新进入 app 的信息填写界面, 然后点击右上角”注册”按钮, 进行注册.
返回到主界面，点
找到你的帐号并单击点击分配 role 找到刚才注册 app，分配所有权限，并保存；然后退出再重新登录一次，即可访问 app.即可访问
具体操作请参见: https://developer.mindsphere.io/zh/howto/howto-cf-running-app.html
当 developer 在自己 tenant 下, 开发完成 app 过后, 这时可以进行将项目移交至 validator 类型的 tenant 进行 app 的安全性之类的进行验证.
3.1. 代码的 Upload 点击”Developer Cockpit”, 选择自己的项目点击进入, 到 app 详情点击右上角”管理上传”按钮:
当点击”管理上传”按钮后, 会出现如下界面:
此时, 请确保”组件”中的个数和 manifest.yml 中定义的需要上传的 app 个数一致, 且也需和上传的.zip 包中的 app 个数一致!!!
1.如果 app 由多个构成，那么请将前端项目文件夹和后端项目(例如一个前端项目的文件夹和一个后端的.jar)打成一个.zip压缩包. .zip 只含有这个前端项目的文件夹和.jar(如果是 Java 语言开发的话).也就是说, manifest.yml 文件里面每个 app 的 path 属性，只能使用相对路径，而且都是相对于 manifest.yml(即 path: ./test.jar 或者 path: ./folder.), 且勿使用绝对路径(如
C://folder/myproject/test.jar).
2.压缩包名字任意, 但请以.zip结尾!!!(这里请注意, 请勿将您要上传的 manifest.yml 文件放在.zip 包里, 也就是说.zip压缩包只能包含要上传的文件内容, 别有 manifest.yml 文件, 因为这容易导致后续的勿操作, 切记!!!).
3.如果在 Developer 的 Cloud Foundry 中, 您的 app 绑定了某些 service, 如 postgresql 或者 rabbitmq 的话, 那么在 manifest.yml 中请一定加上 service: service-name 这一项属性 (如果 app 绑定了多个 service, 就使用 services:
service1-name service2-name), 而且在上图中, 也一定要选择 app 所绑定了的 service 信息!!! 然后右侧需要上传的 manifest.yml 文件, 就选择对应 push使用的那一个 manifest.yml.然后点击”上传”.
上传提交成功过后，点击批准上传
点击”批准”按钮, 输入 Alternate Email；如果想放弃本次上传, 点”放弃”即可.
点击”批准”过后, 当弹出下面的框时, 应用就已被上传了, 等待接下来的 validation . 接下来的操作, 就是 MindSphere 团队进行 validation 的操作了. 你只需要查看 Developer Cockpit中 validation 进行的情况即可，正常流程是 5 天内会完成。如有疑问或加急，可以 support 团队进行联系。备注: 针对应用大于 250M的时候, 客户需要进行单独的操作:
1. .zip 代码包大于 250M, 那么此时用户上传的这个压缩包需要先暂时上传一个额外的可以称作 fake package. 但是这个临时的压缩包, 里面的目录结构一定和之后上传的 manifest.yml 文件定义的 path 相匹配.至于客户如何将代码上传给 validation 的人员, 目前
利用 Secure File Exchange(https://secufex.erlm.siemens.de/secufex/secufex.do?reqCode=secufex)系统进行传输.
输入要分配给的 operator 的 tenant 名字和登录邮箱. 显示分配成功后, 登录对应的 operator tenant 的 MindSphere, 选择”Operator Cockpit”.
点击”收件箱”, 认领 developer 的指派. 然后切换回 developer cockpit 中, 找到刚才分配给 Operator 那个界面, 然后刷新，可以看到”授权”, 点击”授权”. 该 operator 类型的 tenant 便可以进行部署操作了. 切换回 operator cockpit, 点击”应用”, 即可对当前应用进行操作.
5.1. 部署点击 app 进入, 选择部署:
自动部署: 前提是, 从 developer cockpit 那里上传的 manifest.yml 中，需要指定 random-route: true; 然后 buildpack 属性要存在，且不能是 buildpacks，这样才能进行自动部署。由于本 app 之前 manifest.yml 使用的 buildpacks，所以这里无法进行自动部署。 手动部署: . 点击开始 下载 app，切忌一定要点击从这里下载的 app 来进行后续的 cf push!!! 下载过后，解压压缩包，然后按照本文档”1. 部署、注册 App 步骤”这一节，再重新部署一次即可。但是，这里需要首先切换到 operator 的 org 当中，根据 app 的 internal name 创建一个 space，即: 复制这个名字 然后根据下图序号执行切换 space，然后即可正常 push。
